0

最近、私はTDDの方法論に従おうとしていますが、これにより多くのサブクラスが作成され、依存関係などを簡単に模倣できるようになります。

たとえば、、、などのように適用できるメソッド/操作があると言うことができますRecurringProfile。TDDにより、これらはなどのような「小さな」クラスとして実装されます。MarkAsCancelRenewProfileMarkAsExpiredMarkAsCancelService

RecurringProfileたとえば、クラスを持つなどで実行できるさまざまなメソッド/操作の「ファサード」（シングルトン）を作成することは意味がありますかRecurringProfileFacade？これには、コードを実際のサブクラスに委任するメソッドが含まれます。例：

public class RecurringProfileFacade
{
    public void MarkAsCancelled(IRecurringProfile profile)
    {
        MarkAsCancelledService service = new MarkAsCancelledService();
        service.MarkAsCancelled(profile);
    }
    public void RenewProfile(IRecurringProfile profile)
    {
        RenewProfileService service = new RenewProfileService();
        service.Renew(profile);
    }
    ...
}

上記のコードは実際のコードではなく、実際のコードはコンストラクターによって挿入された依存関係を使用することに注意してください。この背後にある考え方は、そのようなコードの利用者は、呼び出す必要のあるクラス/サブクラスに関する内部の詳細を知る必要はなく、それぞれの「ファサード」にアクセスするだけであるということです。

まず第一に、これは「ファサード」パターンですか、それとも他の形式のデザインパターンですか？

上記が理にかなっている場合に続くもう1つの質問は、特定のビジネスロジック機能がないことを考慮して、そのようなメソッドの単体テストを実行しますか？

4

4 に答える 4

2

コードをライブラリとして他の人に公開する場合にのみ、このようなファサードを作成します。他の人が使用するインターフェースであるファサードを作成できます。

これにより、後で実装を変更するための機能が提供されます。

そうでない場合、このファサードはどのような目的を提供しますか？コードの一部がファサードで1つのメソッドを呼び出したい場合、ファサード全体に依存します。依存関係を小さく保つのが最善です。そのため、に依存関係がある場合は、コードを呼び出す方が適切MarkAsCancelledServiceですRecurringProfileFacade。

于 2012-11-29T11:16:26.257 に答える
0

そのような問題に直面するとき、私は通常、YAGNI /KISSの観点から推論しようとします：

  • そもそも、などMarkAsCancelServiceが必要ですか？MarkAsExpiredServiceこれらの操作はRecurringProfileそれ自体でより良い家を持っているのではないでしょうか？

これらのサービスはTDDプロセスの副産物であるとあなたは言いますが、TDD 1.は、すべてのロジックのビジネスエンティティを取り除くことを意味しません。2 。一部のロジックを外部化する場合、サービスに入る必要はありません。抽出したクラスの[BehaviorName]Serviceよりも適切な名前を思い付くことができない場合は、多くの場合、動作を停止して、動作を実際に抽出する必要があるかどうかを再検討する必要があります。

つまり、オブジェクトはまとまりを保つ必要があります。つまり、オブジェクトがあまりにも多くの責任をカプセル化することはできませんが、貧血になることもありません。

  • これらのサービスが正当化されると仮定すると、本当にそれらのファサードが必要ですか？開発者にとって便利なショートカットにすぎない場合は、追加のメンテナンスの価値がありますか（サービスの1つを変更すると、ファサードが変更されます）。あるサービスの各消費者がそのサービスを直接活用する方法を知っていれば、もっと簡単ではないでしょうか。

上記が理にかなっている場合に続くもう1つの質問は、特定のビジネスロジック機能がないことを考慮して、そのようなメソッドの単体テストを実行しますか？

ボイラープレートコードのユニットテストは、実に大変な作業になる可能性があります。その痛みを感じる人もいれば、それは価値がないと考える人もいます。このようなコードは反復的で予測可能な性質を持っているため、1つの適切な妥協案は、テストを自動的に生成することです。さらに良いのは、すべての定型コードを自動的に生成することです。

于 2012-11-28T16:06:41.890 に答える
0

私の意見では、これは一種のファサードパターンです。これは、単純なメソッドの背後でサービスを抽象化しているためです。ただし、ファサードパターンには通常、メソッドの背後にあるロジックが多くあります。その理由は、ファサードパターンの目的が、より大きなコード本体で簡略化されたインターフェイスを提供することであるためです。

2番目の質問については、私は常にすべてをユニットテストします。あなたの場合、それはあなたがプロファイルをキャンセルまたは更新するときにあなたのプロジェクトの状態を変えるのでしょうか？期待どおりに状態が変化したと断言できるからです。

于 2012-11-28T14:49:43.830 に答える
0

あなたのデザインがあなたがあなたのSingletonためにいくつかの仕事をするために使うことができるとあなたに「告げる」なら、それはおそらく悪いデザインです。TDDは、シングルトンの使用について考えることから遠く離れてあなたを導くはずです。

それが悪い考えである（または大丈夫である可能性がある）理由はウィキペディアで見つけることができます

あなたの質問に対する私の答えは次のとおりです。他のパターンを見てください！たとえば、UnitOfWorkとStrategy、Mediatorそしてこれらのパターンで同じ機能を実現しようとすると、それぞれの利点を比較できるようになります。あなたはおそらく何かで終わるでしょうUnitOfStrategicMediationFacade;-)

より詳細な分析については 、 CodeReviewにこの質問を投稿することを検討してください。

于 2012-11-28T15:53:38.200 に答える