名前が同じで名前空間が異なるクラスを持つコード（問題がある場合はC＃）を実行しました。それらはすべて同じ論理的なものを表す傾向がありますが、同じオブジェクトの異なる「ビュー」であることがよくあります。異なる名前空間は、同じソリューションの一部であり、同じdllでさえあります。

私は私の考えを持っていますが、利用可能なツールまたは回避すべきパターンの巧妙な使用と見なすために、この実践について決定的なものを見つけることができませんでした。

スマーフの命名に関するこの質問はこれに触れていますが、別の方向からです。名前の曖昧さをなくすには、恣意的で広範に及ぶ接頭辞が必要になる可能性が高いため、その質問は排除したかった。

この実践に関するガイドラインは何ですか？

私のプロジェクトの1つでもこれを見て作業した後、そのような使用法に対する答えを出そうとします。

コードの読みやすさ

まず第一に、コードの読みやすさが重要であり、この慣行はそれに反することを考慮してください。誰かがコードを読んで、それが関数を持っているとだけ言ってみましょうdoSomething(Employee e)。Employee異なるパッケージに10の異なるクラスが存在するため、最初にインポート宣言を使用して、実際の入力が何であるかを調べる必要があるため、これは読み取り可能ではなくなりました。

しかし、これは高レベルのビューであり、ランダムな名前の衝突がしばしば見受けられます。意味が残りのコードと現在のパッケージから導き出される可能性があるため、誰も気にしたり、見つけたりすることはありません。もちろん、ローカルでは問題ありません。もちろんEmployee、hrパッケージ内を見ると、従業員のHRビューについて話していることを知っている必要があります。

しかし、これらのパッケージを離れるとすぐに、物事は壊れます。別のモジュール/パッケージ/その他で作業していて、従業員と作業する必要がある場合、その型を完全に修飾しないと、読みやすさが犠牲になります。さらに、10の異なるEmployeeクラスがあると、IDEのオートコンプリートは機能しなくなり、従業員のタイプから手動で選択する必要があります。

コードの複製

これらの各クラスは互いに関連しているという性質上、多くの重複によりコードが劣化する傾向があります。ほとんどの場合、従業員の名前や識別番号などがあり、各クラスでこれらを実装する必要があります。各クラスは独自の種類のビューを追加しますが、基礎となる従業員データを共有しない場合は、役に立たないがコストのかかる膨大な量のコードになってしまいます。

コードの複雑さ

あなたが尋ねるほど複雑になる可能性があるものは何ですか？結局のところ、各クラスは必要なだけシンプルに保つことができます。本当に問題になるのは、変更をどのように伝達するかです。適度に機能が豊富なソフトウェアでは、従業員データを変更できる可能性があり、それをあらゆる場所に反映したいとします。ある女性が結婚したばかりで、彼女の名前をからXに変更する必要があるとしますYそのため。あらゆる場所でこれを実行するのに十分なほど困難ですが、これらの異なるクラスをすべて持っている場合はさらに難しくなります。他の設計上の選択によっては、これは簡単に、各クラスが独自の種類のリスナーなどを実装して、変更を通知する必要があることを意味します。これは、基本的に、処理する必要があるクラスの数に適用される要素に変換されます。 。もちろん、コードの重複が多くなり、コードの可読性が低下します。このような要因は、複雑さの分析では無視できるかもしれませんが、コードベースのサイズに適用すると、厄介です。

コード通信

設計の選択にも関連する、コードの複雑さに関する上記の問題とは別に、より高いレベルの設計の明確性が低下し、ドメインの専門家と適切に通信する能力が失われます。アーキテクチャ、設計、または要件について話し合うとき、のような単純なステートメントを自由に作成できなくなりますgiven an employee, you can do ...。開発者employeeは、その時点で実際に何が意味するのかわからなくなります。もちろん、ドメインの専門家はそれを知っています。私たちは皆そうです。ちょっと。しかし、ソフトウェアに関しては、もはやコミュニケーションはそれほど簡単ではありません。

問題を取り除く方法

これを認識しつつ後とあれば、あなたのチームは取り組む問題は大きな十分であることに同意し、その後、あなたはそれに対処する方法を考え出す必要があります。通常、マネージャーにゴミを取り除くためにチーム全体に1週間の休みを与えるよう依頼することはできません。したがって、本質的には、これらのクラスを一度に1つずつ部分的に削除する方法を見つける必要があります。これに関する最も重要な部分は、チーム全体で、Employee本当に何であるかを決定することです。個々の属性のすべてを1人の神従業員に統合しないでください。中核となる従業員についてもっと考え、最も重要なこととして、そのEmployeeクラスがどこに存在するかを決定します。

コードレビューを行う場合、問題が少なくともそれ以上拡大しないことを確認することは特に簡単です。つまり、Employeeもう一度追加したい場合は、すべての人を正しい方向に止めます。また、新しいサブシステムが合意に準拠しEmployee、古いバージョンへのアクセスが許可されないように注意してください。

プログラミング言語によっては、最終的に削除されるクラスにマークを付けることもできます@Deprecated。これは、変更が必要なもので作業していることをチームがすぐに理解できるようにするためです。

古くなった従業員のクラスを取り除くことに関しては、個々のケースごとにどのようにしてそれを排除するのが最善かを決定するか、または一般的なパターンに同意することができます。クラス名を付けてそれを実際の従業員で囲むことができます。パターン（デコレーターまたはアダプターが思い浮かびます）、または、または、またはを使用できます。

長い話を簡単に言うと、この「実践」は技術的には健全ですが、将来的にのみ発生する隠れたコストで一杯になります。問題をすぐに取り除くことはできないかもしれませんが、その有害な影響を封じ込めることからすぐに始めることができます。

Scalaコレクションフレームワークは、この良い例です。変更可能なコレクションと不変のコレクションだけでなく、シリアルコレクションと並列コレクション（将来的には分散される可能性もある）コレクションがあります。したがって、たとえば、次の4つのMap特性があります。

scala.collection.Map
scala.collection.immutable.Map
scala.collection.mutable.Map
scala.collection.concurrent.Map

プラス3 ParMaps：

scala.collecion.parallel.ParMap
scala.collecion.parallel.immutable.ParMap
scala.collecion.parallel.mutable.ParMap

さらに興味深い：

scala.collection.immutable.Map            extends scala.collection.Map
scala.collection.mutable.Map              extends scala.collection.Map
scala.collection.concurrent.Map           extends scala.collection.mutable.Map

scala.collecion.parallel.ParMap           extends scala.collection.Map
scala.collecion.parallel.immutable.ParMap extends scala.collecion.parallel.ParMap
scala.collecion.parallel.mutable.ParMap   extends scala.collecion.parallel.ParMap

したがって、ParMapextends ParMapextends MapとMapextends Mapextends Mapです。

他に何：しかし、それに直面させます、あなたはそれらを呼び出しますか？これは完全に理にかなっています。それが名前空間の目的です！

これは、2つの本質的に反対の答えがどちらも正しい、本当に興味深い質問です。これは、私たちのプロジェクトで行っているこのディスカッションの実例です。

@Jorgと@Frankの2つの答えを参考にして、これまでにどちらか一方の方向に進みたいという2つの非常に重要な考慮事項があると思います。

1. 同じコードコンテキスト内で複数の同じ名前のクラスを使用する必要がある状況が予想される場合、これが同じ名前を使用しない理由です。つまり、を使用する必要hr.Employeeがあるが、を介して権限を確認する必要がある場合、security.Employee非常に煩わしくなります。
2. 逆に、同じ名前のクラスがすべて同じまたは非常に類似したAPIを持っている場合は、異なる名前空間で同じ名前を使用する必要がある場合の良い例です。Scalaの例はまさにこれで、すべてのMapクラスが同じインターフェースを実装するか、互いのサブクラスです。この場合、ユーザーはクラスまたはインターフェースのすべての実装を同じように正しく扱うことができるため、あいまいさまたは「混乱」は間違いなく良いことと呼ばれる可能性があります。これがインターフェースとサブクラスのポイントです。