は2.4から2.5へのアプリケーションの移行（およびすべての静的参照を取り除く）の私の過程でプレイ2.5

Question

に依存注射と継承を組み合わせることで、私は次のことを行っている：

class Generic @Inject()(implicit val mat: Materializer, cache: CacheApi, wsClient: WSClient, configuration: play.api.Configuration) 
{ ... } 

@Singleton 
class Concrete1 @Inject() (gw:Generic) { ... } 

@Singleton 
class Concrete2 @Inject() (gw:Generic) { ... } 

それを使用するには、私は、GenericのインスタンスをConcrete1/2に注入します。 それはうまくいきますが、Web上のそれに関するいくつかの他の例を見た後、それはかなり正しいように見えません。

私はこのようにそれを修正することについて考えています：

abstract class Generic(cache: CacheApi, wsClient: WSClient, configuration: play.api.Configuration) 
    { ... } 

    @Singleton 
    class Concrete1(cache: CacheApi, wsClient: WSClient, configuration: play.api.Configuration) 
     extends Generic(cache, wsClient, configuration) { ... } 

    @Singleton 
    class Concrete2(cache: CacheApi, wsClient: WSClient, configuration: play.api.Configuration) 
     extends Generic(cache, wsClient, configuration) { ... } 

次に行うことができるようにするために：@Inject() (c1:Concrete1, c2:Concrete2) 私はで定義されたように私は彼らがモジュールである必要が推測：https://www.playframework.com/documentation/2.5.x/ScalaDependencyInjection#Programmatic-bindings？ ここでは何が理にかなっていますか？

Answer 1

私は実際にあなたの "かなり正しいとは思われません"というステートメントに同意しませんでした。

は、私はあなたの最初の例では、より密接に継承オーバー構図ソフトウェアを構築するためにaccepted as a more maintainable wayとなっている哲学を反映していると主張するだろう。あなたのConcreteまたはGenericクラスについては何も知らず

は、それはより多くを語るのは難しい、しかし、に適切にユニットテスト簡単に後者、継承ベースの構造だった場合、それは次のようになり、一方、私は、非常に驚くだろう簡単にGenericを模擬し、それをテストのConcreteクラスに注入する。

その他の利点：

• ノイズの少ない/繰り返しの宣言
• 少ないあなたの具体的なクラスが第二「の共通を共有するときのためのフレームワーク（モジュール定義は必要ありません）
• 将来の柔軟性を（再生するために結ば"クラス）