2017-01-15 8 views
0

次の問題があります。たとえばUserExpactationsというインターフェイスがあり、いくつかのロジックを確認するためにbuilder-styleに多数のメソッドがあります。インターフェイスから一般的なメソッドを抽出します。

はこのようになります:あなたは、各メソッドがUserExpactationsを返すことができたよう

interface UserExpectations { 
    UserExpectations expectSuccessResponseFromApi; 
    UserExpectations expectFailResponseFromApi; 


    UserExpectations expectUserInDB; 
    // more user-specific methods 
} 

ので、我々はそれらを一緒に連鎖することができます。

もう1つのexpectatorクラスを追加する必要があります。いくつかの共通ロジック、つまり最初の2つのメソッドがあります。

だから、このように見えるようになるだろう:

interface OrderExpectations { 

    // these are common to UserExpectations 
    OrderExpectations expectSuccessResponseFromApi; 
    OrderExpectations expectFailResponseFromApi; 


    OrderExpectations expectOrderInCart; 
    OrderExpectations expectOrderInDB; 
    // some more order specific methods 
} 

を私は抽象クラスまたは多分別のトップレベルインターフェースにこれらの一般的な方法を抽出したいです。そして、これらの方法は1つの場所に実装する必要があります。そして、それぞれのexpectatorsは、その実装を認識している必要があります。しかし問題は、メソッドを連鎖させる能力を維持するために、それぞれの共通メソッドが特定の*Expactations型を返さなければならないことです。

これを実装する方法が見つかりません。たぶん、私が気付いていないこの問題を容易にするのに役立つ良いパターンがあります。 アイデア

更新日:

このよう

abstract class CommonExpactations<T> { 
    T expectSuccessResponseFromApi() { 
     // do some logic and then return T 
    } 
    T expectFailResponseFromApi() { 
     // do some logic and return T 
    } 
} 

ではなく、それぞれの実装*期待の特定のインターフェイスがすべき

は、だから私は、一般的な方法が含まれます抽象Expecationsを作成したいです共通メソッドへのアクセスを得るためにCommonExpactationsを拡張します。 しかし、javaでは抽象クラスでTタイプの新しいオブジェクトを作成することはできません。具体的な実装では他のメソッドを連鎖させるためです。ですから、例えば

UserExpectationsImpl implements UserExpectations extends CommonExpactations<UserExpectations> 
+0

ジェネリック経由でないと言う、そして持っている '保護抽象TのnewInstance();'それはサブクラスによって実現されます。 –

+0

あなたの "更新"のための[mcve]を投稿するべきです(2番目のメソッドの返り値の型に 'T UserExpectations expectFailResponseFromApi'があることにも注意してください)。 –

答えて

1

どのようにジェネリック医薬品とは?

public interface Expecations<T> { 
    T expectSuccessResponseFromApi(); 
    T expectFailResponseFromApi(); 
    .... 

} 


public interface UserExcpectations extends Expecations<User> { 

} 
+0

expectOrderInCartまたはexpectOrderInDBについて何も知る必要はありません。しかし、あなたの例ではそうしていますし、さらにこれらの一般的な方法を実装したいと思いました。したがって、この場合、UserExcpectationsとOrderExpectationsの各実装は、その実装へのアクセスを持ちます。 – user3127896

+0

@ user3127896、expectOrderInCart&expectOrderInDBは、OrderExpectationsインターフェースのメソッドです。これらはUserExpectationsインターフェイスには共通していません。 UserExpectationsがそれらの方法について知っているところはありません。目的は、UserExcpectations&OrderExpectationsインターフェイスの一般的なメソッドを抽象化することです。はいの場合は、提案された答えに従って、Expectationsインターフェイスを持ち、UserExcpectationsとOrderExpectationsの両方のインターフェイスで拡張します –

+0

正しいですが、インターフェイスでの宣言だけでなく、これらの一般的なメソッドの実装をしたいと思っています。 – user3127896

0

抽象クラスの匿名オブジェクトの作成を試してください。 CommonExpectationsの子インターフェイスで

abstract class CommonExpactations<T> { 
    T expectSuccessResponseFromApi() { 
     // do some logic and then return T 
    } 
    T expectFailResponseFromApi() { 
     // do some logic and return T 
    } 
} 

は、UserExpectationsは

CommonExpectations ce = new CommonExpectations<UserExpectations>(){ 

    //provide abstract method implementations 
} 
+0

何がポイントですか?実装は、各子インタフェースではなく1か所に配置する必要があります – user3127896

関連する問題