アプリケーションをコンパイルして実行するために名前空間が必要ないことを私は証明しました。しかし、名前空間を使用しないことの危険性と落とし穴は何ですか? それは私が避けようとしているレイヤーを作成します。
あなたが叫んでいるのは知っていますが、コードとオブジェクトの間に 20 層の抽象化が存在するように、アジャイルと抽象化についてはどうでしょうか。それが今月のアジャイルのあれやこれに違反しているかどうかは尋ねていません。名前空間を使用しないことで、実際にどのような問題が発生するのでしょうか?
編集：
スタンドアロン クラス dll を作成して、クラス プロジェクト内で競合が発生しないようにします。完全修飾名を使用する必要がある他のプロジェクトに含めるときは避けようとしています。myNamespace.myClass MyClass = 新しい myNamespace.myClass();
コメントから、名前の競合が最大の問題であるように見えます。
usingステートメントを使用してバックアップする必要があると思います...
名前空間には、主に次の 2 つの用途があります。
まず、コードの消費者がコードをより簡単に理解し、見つけ、正しく使用できるようにします。System.Diagnosticsシステム診断ツールが名前空間にあるのには理由があります。顧客がそこにあるものが何のためにあるのかを知ることができるようにするためです.
第二に、それらは名前の競合を防ぐためのメカニズムです。
最初のものは、実際にははるかに重要です。競合はそれほど一般的ではありません。それでも、それらは可能であり、名前空間を適切に使用することでそれらを防ぐことができます。
顧客がコードを見つけ、理解し、使用することを気にせず、名前の競合がない場合は、名前空間の使用をスキップしてください。
それは私が避けようとしているレイヤーを作成します。
実際に追加の「レイヤー」が作成されることはありません。名前空間は純粋に型を整理する方法を可能にし、プロジェクトが大きくなり、より多くのライブラリが使用されるときに名前の衝突を防ぐのに役立ちます。
ランタイムに関する限り、名前空間はありません。すべての型は完全修飾されており、C# の名前空間は型名を変更するだけです。名前空間をオフのままにしておくと、型名が他の名前と競合する可能性が高くなりますが、プロジェクトで同じ名前を複数回使用しない限り、コードが機能するかどうかに「実際の影響」はありません。参照されたアセンブリからの型の名前と同じ名前を使用し、 を介してインポートしusingます。
コメントに応じて編集：
「レイヤーを作成する」とは、オブジェクトを作成するときに名前空間をレイヤーとして追加する必要があるということです。(つまり、myNamespace.myClass MyClass = new myNamespace.myClass();) "
これは、using myNamespace;ステートメントがない場合、またはプロジェクト内で複数の名前空間を使用する場合にのみ必要であることに注意してください。プロジェクトの既定の名前空間内で常に作業している場合は、名前を修飾する必要はありません。
名前空間のない生活がどのように見えるかを比較することは良い考えかもしれません。C 言語は名前空間をサポートしていません。そして、その存在の非常に早い段階で、ファイルを開くために open() 関数が使用されていました。
つまり、C プログラマーが自分の関数に「open」という名前を使用することはありません。
痛いですよね？
名前空間は、短くてわかりやすい名前を使用するのに役立ちます。レイヤーを追加するのではなく、より長い名前を作成するだけです。非常に簡単に短く記述できることは、usingディレクティブを使用すると簡単になります。