c# - リファクタリング: ネストされたクラスまたは個別のクラス?

Question

私は現在、いくつかのフレームワーククラスにリファクタリング (+ 新機能の追加) を行っています。状況は、分割したい一連のロジックを実行する単一の (神のような) クラスがあるということです。このクラスは、会計コードの検証規則のようなものを表します。そのため、人の名前、生年月日などの検証を行います.

私がやろうとしているのは、それを単一のルールに分割することです。基本的には、会計コードに対して個人の名を検証するルール、生年月日などを検証するルールです。最後にプログラマーにとっては、ほとんど同じように見えます。FiscalCode ルールの巨大なコンストラクターを呼び出す代わりに、彼は次のようなことをFiscalCode.GetRules(...)行い、ここでパラメーターを渡します。次にGetRules(...)、は単一のルールを内部的に構築し、それらを配列として返します。それは完全に問題なく、私たちにとって正しいです。

あなたの背景についてはこれで終わりです。今、私の質問は次のとおりです。FiscalCode クラス (現在の強力な神のクラス) には、これから作成する単一の「ルールクラス」の多くで必要となるユーティリティメソッドが多数あります。私が知っていることは、それを行うために何らかの形で FiscalCode クラスが必要になるというGetRules(...)ことです (これは、プログラマーがまったく新しいことをしなければならないということではなく、プログラマーにとって何らかの形で一定であり続けるためです)。

私の頭に浮かぶ2つのオプションがあります。

新しいルールクラスを作成し、FiscalCode クラスの public static ユーティリティメソッドにアクセスする
新しいルールクラスを FiscalCode クラス st の内部のネストされたクラスとして作成します。既にユーティリティメソッドにアクセスしています (したがって、ユーティリティメソッドを公開する必要はありません)。

私はすでにお気に入りを持っていますが、最初にいくつかの意見を聞きたいです。

どうも

score 2 · Accepted Answer

メソッドが「ユーティリティメソッド」になったので、それらを静的かつパブリックにする必要がありますが、おそらく FiscalCode の名前を FiscalCodeUtil に変更する必要があります。したがって、どのようなメソッドが含まれているかは明らかです。

score 1 · Accepted Answer

また、このタイプの問題にアプローチする方法についての方向性を示す仕様パターンのレビューをお勧めします。この投稿では、C＃の例もいくつか示しています。

提案された仕様パターンは、オプション＃1に向けてあなたを導きます。

score 0 · Accepted Answer

これらのユーティリティメソッドは、FiscalCode クラスまたはルールクラスに対してどのような依存関係がありますか? それらによって保持されている状態はありますか？

依存関係がない場合は、これらのユーティリティメソッドを別のクラスに移動し、必要に応じて FiscalCode クラスまたはルールクラスでそれらのメソッドを呼び出すことをお勧めします。

指定したオプションについて、1) と 2) の唯一の違いは、ルールクラスがそれらを使用しないクラスに表示されるかどうかです。それは本当に重要な目的ではないと思います。私がC++をやったとき、私はいつもそれについて心配していました...それは時間の無駄でした.

score 0 · Accepted Answer

IMO では、最初のオプションを選択する必要があります。これにより、新しく作成されたクラスを外部に公開し、他の場所でも再利用可能なコードを記述できるようになります。2 番目のオプションを選択すると、非常に特殊なクラスが作成されます。外部コードはその存在を知らないかもしれませんが、カプセル化には適しているかもしれません。それでも、ある時点で、より大きなクラスの範囲外で特殊なルールを使用することを決定する場合があり、そのシナリオでは、最初のオプションを使用する方が適切です。あなたの選択は何ですか？

score 0 · Accepted Answer

クラスがクラス外で使用されない場合は、FiscalCodeネストしてください。重要なことは、この新しいクラスの責任をから引き出すことですFiscalCode。それが存在する場所は、単なる選択の問題になります。新しいクラスの依存関係が増えたら、それを外部クラスにすることができます。

score 0 · Accepted Answer

私は次のようにします（私はOOPが得意ではないので、塩の粒でそれを取ってください）：

ルールクラス (FiscalCode にネストされている) は、ルールメソッドを公開する IRule インターフェイスを実装します (Validate() など、戻り値の型がボートをフロートさせます)。FiscalCode には、ルールの内部コレクションを管理し、メソッドチェーンを許可するために self への参照を返す AddRule() メソッドがあります。

FiscalCode fc = new FiscalCode();
fc.AddRule(new RuleClass1(<params specific to RuleClass1>)
  .AddRule(new RuleClass2(<params specific to RuleClass2>)
  ...

また、FiscalCode には、各ルールの Validate() を反復処理してエラーを管理する Validate() メソッドがあります。

IMO これは非常に使いやすく、ネストされたルールクラスが FiscalCode のユーティリティメソッドにアクセスすることを許可します。

c# - リファクタリング: ネストされたクラスまたは個別のクラス?

6 に答える 6

Related

Reference