問題タブ [newable]

Misko Heverys の洞察に従ってアプリケーションを設計しようとしています。これは興味深い実験であり、挑戦です。現在、ViewHelper の実装に苦労しています。

ViewHelper はモデルをビューから分離します。私の実装では、モデルをラップし、ビューが使用する API を提供します。私はPHPを使用していますが、実装が誰にとっても読みやすいものであることを願っています:

私のテンプレート（ビュー）ファイルでは、これは次のように呼び出すことができます：

ここまでは順調ですね。私が抱えている問題は、ViewHelpers にフィルターをアタッチしたいときです。title() 呼び出しの出力をフィルタリングするプラグインが必要です。メソッドは次のようになります。

そこにオブザーバー、EventHandler、またはその他のサービスを取得する必要があります (newable と見なされるため、スタックを介して渡す必要があります)。Misko Hevery の原則に従ってこれを行うにはどうすればよいですか? 私はそれなしでこれを行う方法を知っています。どうやってそれを取ることができるかに興味がありますが、現在、解決策がわかりません。ViewHelper も注入可能ですが、そこにモデルを取得することが問題です。

システムを値オブジェクトとサービス オブジェクトに分割すると仮定します (「テストによって導かれるオブジェクト指向ソフトウェアの成長」で提案されているように)。

値オブジェクトの 1 つが突然サービスにアクセスしてそのメソッドを実装する必要がある場合はどうなりますか?

素敵でシンプルな Value オブジェクトがあるとしましょう。それは不変で、いくつかの情報を保持しています。それだけです。次のように使用するとしましょう。

ここまでは順調ですね。 isValid()カード番号にチェック ディジット アルゴリズムを実装し、true/false を返します。

ここで、現在の時刻に対して有効期限を検証することでシステムを強化したいとしましょう。値オブジェクト/サービス オブジェクトのパラダイムを壊さずにこれを行うにはどうすればよいでしょうか? このクラスが引き続き単体テスト可能であってほしいと思います。

• CreditCard現在は依存関係がありますが、作成方法が原因で注入できないため、依存性注入はアウトです。
• クラスはシングルトンを呼び出すべきではありません（CreditCardシングルトンへのグローバルアクセスは悪い習慣であるという立場です）
• 動作をオンにCreditCardVerificationService.validateCard()するということは、既存のすべてのコードを再検討する必要があることを意味します。isValid() の実装がリークしています。

これを回避するためにできることがあることは知っていますが、最もクリーンな方法は何ですか?

コードを書くとき、オブジェクトの 2 つの大きなグループを識別できるはずです。

• 注射剤
• ニューエイブル

http://www.loosecouplings.com/2011/01/how-to-write-testable-code-overview.html

http://misko.hevery.com/2008/09/30/to-new-or-not-to-new/

• 注入可能オブジェクトは、コンストラクターで依存関係を公開するオブジェクト (サービス) です。これらの依存関係は通常、IoC コンテナーを使用して解決されます。これらのオブジェクトは、コンストラクターで他の注入可能オブジェクトのみを要求できます。

• Newable はコンストラクターで依存関係を公開するオブジェクトですが、newable は他の newable オブジェクト (エンティティ、値オブジェクト) のみを要求できます。newable オブジェクトのもう 1 つの特徴は、注入可能なオブジェクトへの参照を保持してはならないことです。

しかし、コードを書くとき、多くの場合、サービス (注入可能) をエンティティ (新規可能) に「注入」する必要があります。

newable オブジェクトでサービスの依存関係を公開する方がメソッド レベルで行うほうがよいのではないかと考えていましたが、これはやるべきことがたくさんあるように思えます....メソッドが呼び出されるたびに依存関係を解決することを考えているだけです... . これは、Service Locator アンチパターンを使用する必要があるように思えます。

私がこれを解決した方法は次のとおりです。

• 依存関係を公開するメソッドを使用してインターフェイスを作成します (サービスはこのメソッドで使用されます)

• インターフェイスの拡張メソッドを作成し、別の名前空間、おそらく別のアセンブリに配置し、サービス ロケーターを使用して依存関係を解決する元のメソッドへの呼び出しをラップするだけです。

これを行うことで、newable オブジェクトと注入可能オブジェクトを一貫して分離し、newables でサービスを簡単に使用できるようになります。

• どう思いますか？
• 拡張メソッドでサービス ロケーターを使用することは悪い習慣と見なされますか?
• 拡張メソッドの呼び出しをどのように単体テストしますか?

これで試しましたが、うまくいきません。Foo は何が機能するかの単なるテストです。バーは本当の試みです。新しい型を受け取る必要がありますが、オブジェクトのサブクラスはその目的には有効ではありません。