0

一般的なシステムでの名前空間とクラスの命名に関するベスト プラクティスについては、多くの適切なガイダンスがあります。

利用可能なガイダンスでは対処されない問題を引き起こすシステムをモデル化しています (少なくとも私はそれを見つけることができません)。システムには当然、同じ名前を共有するいくつかのクラスがあります。

簡単にするために、問題の本質を捉えたドメインの例を使用します。

オプション 1: 名前空間と名前空間のエイリアシングを使用して、コード内のクラスを区別できます。クラスは、名前空間全体での重複を気にせずに命名されます。

サッカー.攻撃.戦術

class Play { }

サッカー.ディフェンス.戦術

Class Play { }

Offensive = Football.Offense.Tactics の使用

ディフェンシブ = Football.Defensive.Tactics の使用

{

Offensive.Play offensivePlay = new Offensive.Play();

Defensive.Play defensivePlay = new Defensive.Play();

}

オプション 1 問題:

  • ジュニア開発者を混乱させる可能性があります。
  • 名前空間を消費するすべてのものにエイリアスを追加すると、オーバーヘッドが発生します。
  • エイリアシングを使用しないと、誰にとっても混乱するコードになります。

オプション 2: 名前空間を使用する代わりに、本質的に名前空間のセマンティクスを組み込んだクラスに名前を付けます。（オフェンシブプレーとディフェンシブプレー）。

オプション 2 問題:

  • 長いクラス名の可能性。例: OffensivePresnapAdjustmentType

  • 名前空間のセマンティクスをクラス名に埋め込むと、クラス名が繰り返されます。

    • オフェンシブベースプレイ
    • オフェンシブフォーメーション
    • オフェンシブプレー
    • オフェンシブプレイヤー
    • 攻撃的なパッケージ
    • オフェンシブPresnapAdjustment
    • オフェンシブPresnapAdjustmentType
    • （そして、さらに多くの防御的同等物に加えて。）
  • あまり効果のないインテリセンス (Visual Studio)

オプション 3: Football.Offense と Football.Defense の 2 つのアセンブリを作成します。(これはオプション 1 と同じで、さらにきれいに分離できる可能性があります)

オプション 3 問題:

  • オプション 1 と同じ問題。
  • 複数のアセンブリの複雑さを紹介します。

私は 1 番目または 3 番目のオプションに傾倒していますが、将来のリリースで多くの面倒な名前空間とクラス名のリファクタリングが必要になるかどうかを判断するのに十分な実務経験がありません。

名前空間を設計し、クラスに適切な名前を付けて、いくつかのメジャー リリースでの時間の試練に耐えられるようにしたいと考えています。

この状況でのベストプラクティスについてどう思いますか?

4

1 に答える 1

1

私が問題だと思う名前空間を本当に理解していません。

守備戦術と攻撃戦術でのプレーは、実際にはどのように異なるタイプのオブジェクトなのでしょうか。

いくつかのプレーは防御的な戦術であり、いくつかは攻撃的です。つまり、守備と攻撃はプレーの特性であり、その逆ではありません。

名前空間は単なる組織単位です。

ファイル ローダーに名前空間を使用し、戦術エンジンに別の名前空間を使用できます。

play メソッドを備えた IPlay インターフェイスと、それらを実装するある種の戦術クラスを持たないのはなぜですか。名前空間が必要な理由や、自然に機能するオブジェクト構造を逆にしたい理由がわかりません。

あなたは、より具体的なものをより一般的な階層の位置に置こうとしています。したがって、なぜあなたは痛みを感じているのですか。

于 2013-05-23T13:17:00.460 に答える