リファクタリング：ネストされたクラスまたは別のクラス？

Question

私は現在いくつかのリファクタリング（新機能の追加）をいくつかのフレームワーククラスに行っています。状況は、私たちが分裂したい論理の束をする単一の（神のような）クラスを持っていることです。クラスは、会計コードの検証ルールのようなものを表します。それで、人の名前、誕生日などの検証を行います。

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

今私の質問は次のとおりです。 FiscalCodeクラス（現在の強力なgodクラス）は、私が作成しようとする単一の "ルールクラス"の多くで必要となる多くのユーティリティメソッドを持っています。私が知っているのは、GetRules(...)のことをするためにFiscalCodeクラスがまだ必要なことです（これはプログラマーにとっては何となく変わりません。まったく新しいことをする必要はありません）。

2. がの内部にネストしたクラスとして私の新しいルールのクラスを作成しますFiscalCodeクラスのパブリック静的なユーティリティメソッドを私の新しいルールのクラスを作成し、アクセス：

   私は私の心に来て、2つのオプションがありFiscalCodeクラスst私は既にユーティリティメソッドにアクセスしています（したがって、私のユーティリティメソッドを公開する必要はありません）

私はすでにお気に入りですが、最初にあなたの意見を聞きたいと思います。

Thxを

Answer 1

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

Answer 2

これらのユーティリティメソッドは、FiscalCodeクラスまたはルールクラスにどのような依存関係がありますか？彼らは国家を守っていますか？

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

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

Answer 3

IMOこの方法では、新しく作成したクラスを外部に公開することができますし、他の場所でも再利用可能なコードを書くことができます。 2番目のオプションを使用すると、非常に特殊なクラスが作成されます。あなたの外部コードはその存在を知ることさえできないかもしれませんが、それはカプセル化には良いかもしれません。しかし、ある時点では、より大きなクラスの範囲外で特殊ルールを使用することを決めることがあります。そのシナリオでは、最初のオプションでより効果的です。あなたのピックは何ですか？

Answer 4

クラスがFiscalCodeクラスの外側で使用されない場合は、ネストします。重要なことは、この新しいクラスの責任をFiscalCodeから引き出すことです。それが存在する場所は単なる選択の問題になります。新しいクラスがより多くの扶養を取得すると、それを外部クラスにすることができます。

Answer 5

私は、この（私は塩の粒とそれを取るOOPの良いことではないよ）のようにそれで行くだろう：のような（ルールのメソッドを公開するのiRuleインタフェースを実装（FiscalCodeにネスト）

ルールのクラスValidate（）、戻り値の型はボートを浮動させます）。 FiscalCode は、ルールの内部コレクションを管理し、方法チェーンを可能にするために自己への参照を返す追加ルール（）メソッドを有する。

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

また、FiscalCodeが各ルールの検証を通った反復検証（）メソッドを持っています（）とエラーを管理します。

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

Answer 6

Specification Patternのレビューをお勧めします。これは、このタイプの問題に近づく方法の方向性を示しています。 This postはまた、C＃でいくつかの例を示します。

提案されたSpecification Patternは、あなたのオプション＃1に向かうでしょう。