私のチームは、1 つの製品 (ただし多くのファセットを含む) を VB6 から .Net (最大 30 万 LOC) に変換する変換プロジェクトに取り組んでいます。私が参加する前に、アセンブリの場所やフォルダー構造に関係なく、すべてのクラス/構造体が 1 つの名前空間にあるという決定が下されました。
.
自動生成されたアプリケーション設定デザイナー コード、リソース デザイナー コードなどを変更して、統一性を強制することさえあります。名前空間の使用が適切であることを彼らに納得させるにはどうすればよいですか? 名前空間の適切な使用とは何ですか?また、長所と短所は何ですか? なぜ私の同僚が回線を使って節約するのにそんなに苦労するのか理解に苦しむことになると思います。あなたの議論をサポートするための外部の評判の良い参照は、非常に高く評価されます. 助けてください！
私は多くの良い答えを読みました (たとえば、オブジェクト/概念の分離/組織と同様に、ドライブ フォルダーのイメージは良いものです)。
それでも、名前空間が代替案よりも優れている理由を説明するためではなく、名前空間が使用されない悪い理由を明らかにするために、「技術的」ではない他のいくつかの議論が役立つ可能性があります。
すべての C#、VB.NET、Java、C++ など、この地球上で有能な開発者は、名前空間/パッケージが優れていることを認めています。ねえ、彼らは Mozilla の JavaScript でもそれを検討しています。
スタックオーバーフローに関するあなたの質問には、「権限の引数」のタッチがあると思います... ^_^
あなたは「古い習慣」に陥っていると思います。
私は VB6 の古い習慣に対して VB.NET について直接経験したことはありませんが、C++ については単純化された C ライクな C++ に対して行います。
従来の習慣に対処する場合、作業の半分は、認識せずに既に名前空間を使用していることを発見することです。
たとえば (これは、C++ 開発者が「昔ながらの」C ライクなコードと衝突する場合に最も当てはまりますが、どこでも実行可能だと思います)、シンボルに接頭辞を使用しますか。
彼らは持っていますか：
クラス/シンボル、およびアカウントの「ユーザー」はログインの「ユーザー」と同じではないことを説明し、それらを区別するためのプレフィックスは?
「パターン」は、シンボルにモジュールのプレフィックスを付けると、天井を通り抜けます（コードが十分に大きい場合、これは確かに当てはまります）：
MyUtil DLL、MyKernel DLL および MyGui DLL はありますか? したがって、あなたは持っていますか：
クラス/シンボル?
はいの場合は、すでに名前空間を使用していることを認める必要があります。
そうでない場合は、コードベースが小さすぎるか (ただし、「9 つのプロジェクト」ではそうではないと教えてくれます)、または名前の競合の問題が定期的に発生しています。名前空間。
作業の残りの半分は、彼らの「名前空間」が言語に組み込まれているものよりも優れている理由を説明させることです (これは、致命的な暴露の脳死の推論のために、欲求不満で壁に頭をぶつけないようにする必要がある瞬間です) 。 .
繰り返しになりますが、Argument by Authority を使用できます (何? Microsoft のトップ ガン エンジニアよりもよく知っていると思いますか? ) 。彼らが使用する（または使用しない）もの。
VB.NET/.NET については、すでに十分な議論があり、C++ 名前空間の背後にあるものについては話題から外れるため、ここでは触れません。
しかし、少なくとも、組み込みの名前空間を使用すると、上記のプレフィックスはオプションになります。インターネットからの例を引用します (私は VB.NET についてあまり詳しくありません):
Imports MyWholeProject
Class HelloWorld
Public Sub Main()
Dim o As MyModuleAAA_MyObject = New MyModuleAAA_MyObject
Dim t As MyModuleBBB_MyThing = New MyModuleBBB_MyThing
Dim g As MyModuleCCC_MyGizmo = New MyModuleCCC_MyGizmo
REM etc.
End Sub
End Class
名前空間が有効になっているよりもかなり冗長です。
Imports MyWholeProject.MyModuleAAA
Imports MyWholeProject.MyModuleBBB
Imports MyWholeProject.MyModuleCCC
Class HelloWorld
Public Sub Main()
Dim o As MyObject = New MyObject
Dim t As MyThing = New MyThing
Dim g As MyGizmo = New MyGizmo
REM etc.
End Sub
End Class
そして、冗長性はコードをより不明瞭にし、その結果、バグにつながります。もちろん、MyModuleAAA を MMAAA のようなもっと短いものに置き換えることもできます...しかし、そうすると、よりあいまいなコードなどにつながります..
.NET での名前空間のその他の使用法は、次のように Google で検索できます。
これらの理由は、プロジェクト/キャリア管理に関連しています...
アプリケーションが瀕死の老牛で、ラベルやコンボの内容を変更するのに 2 日間の作業が必要な場合 (実際に発生します)、リファクタリングの余分な作業を行う意味はおそらくありません。一方、リファクタリングが自動化されている場合は、とにかくそれを行う必要があります。
ただし、アプリケーションが将来使用されることになっている場合、それを妨害して過去に保持することは悪い考えです。あなたはいつかそれを支払うでしょう。メンテナンスを回避することで得られるはずの 1 時間は、それがやむを得なくなった日 (つまり、緊急で適切に実行する時間がない日) には 2 倍または 10 倍に支払われます。
この議論は、キャリアがあり、仕事を続けなければならないエンジニア向けです。アプリケーションと同様に、ソフトウェア エンジニアも時代遅れになる可能性があります。
そしてそれは、時代遅れの開発者が別の仕事に応募するときにも失うことを意味します. 名前空間のような単純なものを手に入れられない人に誰がお金を払いたいのでしょうか?
経験は、現在の最先端の知識と相まって良いことです。そうでない場合、それは、「オブジェクトのようなすべてのギズモを必要としなかった私の時代には、どのように優れていたのか（読み方：より単純だった）」についての恐竜時代の冷笑的で役に立たないとりとめのないものです。
言語の新しい機能に適応することを拒否することにより (通常、「私たちはよく知っているからです」)、エンジニアはコンクリートの靴を履いているだけであり、競合他社はおそらくランニング シューズを履いています。これは、時代遅れのチームによって作成されたアプリケーションが最終的に失われることを意味します。限目。
同様の方法で、チームは新しいエンジニアを採用します。彼らはおそらく機能を知っており、何十年も前に祖母が行ったようにプログラミングしているだけであるという事実に驚き、不満を抱くでしょう。時代遅れのチームは、新しいエンジニア (少なくとも、給料に見合うもの) をあまり長く雇用しません。
廃止された製品に取り組んでいると、トップレベルのマネージャーが最初から書き直す方が簡単だと判断しやすくなることに注意してください...そしておそらく、より給料の低いエンジニアやマネージャーがいるどこかで...
名前空間の適切な使用法は、論理的にグループ化されたクラス、インターフェイス、列挙型などの整然とした構造を提供することです。これは、すべてのファイルを単一のフォルダーに配置するようなものです...さらに悪いことに、それらすべてを C: ドライブのルートに配置します...
あなたのチームが非常に近視眼的であることを指摘することは私にはできません.他のチームのポリシーや手順に疑問を呈するのは私の立場ではありません.
あなたのチームがオブジェクト指向設計の原則を理解していることを願っています。関連する情報を、その情報に対して機能する操作を持つクラスにグループ化します。名前空間は似ています (またはそうあるべきです)。名前空間を使用して、関連するクラスをグループ化し、名前空間の集合情報を処理する操作を提供します。
これは、コードの理解に役立ちます。データ層クラスを単一の名前空間にグループ化すると、それらが関連していると識別され、名前空間によって示される機能を提供する方法で関連付けられます [余談ですが、クラスだけでなく名前空間にも意味のある名前を付ける必要があるのはこのためです。 ]。すべてのクラスを同じ名前空間にグループ化すると、すべてが大きな泥の玉になります。コードの構成に対するセマンティックな手がかりを失ってしまったので、必要な機能を提供するために連携して動作するクラスを見つけるためにコードを掘り下げる必要があります。
重要なのは、単に個人的な好みの問題ではないということです。すべての文を 1 つの段落にまとめることが期待できないのと同じように、それらの文が関連している複数の段落にまとめる必要があります。クラスを取り、名前空間に整理する必要があります。文章を関連する文の段落に分割すると、明確さと意味が得られます。クラスを名前空間に分割すると、コードの明確さが向上します。クラスの数が増えるにつれて、これはますます重要になります。
多くの人が指摘しているように、コードの読みやすさと構成。
Network.Session、Meeting.Session、WebServer.Session など、類似した名前のクラスを異なる「スペース」に分離します。実際には、同じ名前または類似した名前を持つオブジェクトが多数存在します。そのため、名前を修飾するために独自のスペースが必要です。System.Web.DLLやSystem.Messaging.DLLのように、名前空間を適切に使用すると、アセンブリの命名も容易になります。これにより、コードを小さな機能チャンク (DLL) に分割して必要に応じて含めることができるため、コードの再利用が容易になります。
名前空間は、さまざまなプロジェクト、目的、およびカテゴリのコードを分離する境界です。多くの DLL ファイルが共有され、再利用される大規模なプロジェクトでは、プログラマーは、正しいクラスを参照し、間違ったクラスを参照しないようにするための簡単に記憶できる方法を必要としています。Microsoft がすべての .NET クラスを 1 つの "System" 名前空間に配置することを決定した場合、手に負えない狂気を想像できますか? プログラマーは、これらのクラスを呼び出すコードをどのように書き始めるのでしょうか? さらに、 WindowsFormsTextBoxやWebUIWebControlsTextBoxなどの名前のクラス、またはそれよりも長いクラスを処理する必要があります。適切な名前空間を持つことで、プログラマーはコードをすばやく安全に書くことができます。
名前空間の利点は、大規模なプロジェクトで、または小さなプロジェクトが問題になるほど大きくなるにつれて、より明白になります。現在のプロジェクトの規模を見て、同僚の腕をねじる必要があるかどうかを判断できます。
名前空間が適切で、健全で、完全に必要であることは間違いありませんが、チームの現状を確立するためにかなりの努力が払われているように思えます。アイデアを売り込む唯一の方法は次のとおりです。
名前空間を持たないことによるコスト (保守性、デバッグなど) について明確な数値を設定し、経営幹部を参加させます。
名前空間の規則の作成を志願し、プロジェクトを変換するためのすべての作業を行います。
残念ながら、私の経験では、名前空間の慣習と同じくらい普及したものが確立されると、それを変更するには議会の行為が必要になります。
一部の人々にとっては、物理的なアナロジーほど説得力のある論理的な談話はありません。
ある日、全員が昼食をとっている間に、オフィスや本棚からすべての本を取り出し、会議室のテーブルに積み上げます。コンピューターの書籍とマンガ コミックや 1 か月前の MSDN マガジンなどを完全に混同してください。
これは 1 つの名前空間を持つことを物理的に表したものであることを伝えます。会議テーブルは名前空間であり、書籍はモジュール/クラス/プロジェクトです。
次に、山の中にある遺伝的アルゴリズムに関する本を見つけてもらいます。（山の一番下に隠してください）。
それでもわからない場合は、あきらめて別の仕事を探し始めます。そんな太った人と一緒に働きたくない！;-)
開発者がVB6と既存のVB6プロジェクトの構造に慣れている場合は、.netのベストプラクティスの一部が損なわれている場合でも、移植されたプロジェクトを元のプロジェクトと非常によく似た構造にすることは理にかなっています。（VB6は名前空間をサポートしていないと思いますか？）新しいコードベースが安定していて、開発者が.netでより快適になったときに、後で名前空間を導入することができます。
単に「唯一の真の名前空間」ではなく、分割された名前空間を持つことが望ましいことであると彼らに納得させる必要がある場合、それはおそらく彼らにそれを納得させることができないことを示しているようです. 正直に言うと。
彼らは名前空間が何のためにあると考えていますか? BCL がそれらを使用する理由は何だと思いますか?
コードが洗濯物だった場合、2 つの選択肢があります。すべてを 1 つの大きな山に保管して、何かが必要になるたびにそれを調べるか、服をビューローに片付けるかです。
名前空間スキームが適切に設計されている場合、コード ファイルの先頭にある using/Imports ステートメントは、このファイルで使用しているものを文書化します。