フラグメントを使用する際にコードが重複しないようにするための最良の方法

Question

Google Playストアで使用可能なアプリを準備しています。

私は既にいくつかのメソッドでBを拡張するクラスを持っていますが、今はCがFragmentActivityを継承しているので、クラスAと同じメソッドを使う必要がありますが、FragmentActivityを拡張しているので、クラスBを使用するので、クラスAと同じ重複メソッドがありますが、メソッドを再利用する必要があります。この例は、以下の

は、私の状況を示しています

例：断片を統合した後

現在の実装

class A extends B{ 

one(); 
two(); 

} 

、

例：

class C extends FragmentActivity{ 

one();// same methods as in class A 
two();// same methods as in class A 

} 

1）この場合、メソッドを再利用する最も良い方法は何ですか？

2）クラスを作成してメソッドを静的にし、AクラスとCクラスの両方でメソッドを再利用するようなアプローチがありますが、私のアプローチは良いですし、静的メソッドを作ることができますそれは良いアプローチですか？

3）私が考えているもう1つのアプローチ"戦略パターン"

Eg: 
class A extends ApiClass { 
    private ClassContainingDupMethod strategy; 
} 

class N extends AnotherApiClass { 
    private ClassContainingDupMethod strategy; 

    public methodCallingDupMethod(){ 
     strategy.dupMethod(); 
    } 
} 

class ClassContainingDupMethod{ 
    public dupMethod(){;} 
} 

"Strategyパターン" です。良いアプローチですか？私は両方のクラスで共通のクラスのオブジェクトを作成する必要があります。

これについてのご意見はありがとうございます。

Answer 1

あなたが説明するよりも簡単です。

クラスを使用する

public class D{ 
    one(); 
    two(); 
} 

変更クラスA D.

public Class A{ 
     public D dLogic; 
    } 

クラスCと同じ

public Class C extends FragmentActivity{ 
     public D dLogic; 
    } 

これは非常にいくつかのことである：あなたがする必要があるのは、このようなDを作成することですオブジェクト指向プログラミングの基本はcompositionです。

Answer 2

いくつかのユーティリティメソッドがあると思われます。クラスUtilsに入れて静的にして、どこからでも呼び出すことができます。私はWifiUtils、LogUtils、NumberUtilsのような私のアプリケーションで多くのユーティリティクラスを持っています。

Answer 3

同じAPIを強制したい場合は、AのインスタンスをCのフィールドに維持しながら、AとCクラスの両方にインターフェイスを追加してみてください。 CはAのラッパークラスとして動作します。

クラスA：

class A extends B implements CommonApi { 
    public void one() { 
     ... 
    } 

    public boolean two() { 
     ... 
    } 
} 

クラスC：

class C extends FragmentActivity implements CommonApi { 
    private A a; 

    public void one() { 
     a.one(); 
    } 

    public boolean two() { 
     return a.two(); 
    } 
} 

Answer 4

あなたはBabibuが言ったことで開始する必要があります - シンプルな構成。

これをマスターすると、他の技術もあります。例えば依存性注入は、ここで使用できるもののように見えます。 シンプルなケースは、このようなものになります。クラスBの代わりにインタフェースBを定義する。Cの初期化中にインタフェースBをパラメータとして渡し、内部変数bとしてb.one（）とb.two（）を呼び出す。 Cスコープの外でBを実装し、アクティビティCの初期化中に渡すオブジェクトAを作成する必要があります。 利点：CはAを作成する方法を知る必要はありません。後でAAまたはAAAに変更することができます.AAおよびAAAがBを実装している場合は、再度アクティビティに触れることはできません。Cを再テストする必要はありません。

Answer 5

両方のフラグメントで同じメソッドがある場合は、BaseFragmentクラス（これはFragmentActivityを継承します）を使用して、そこに共通のメソッドをすべて持たないのはどうしてですか？次に、このBaseFragmentクラスを任意のクラスに拡張することができます。 このようにして、BaseFragmentにあるどのようなメソッドでも、再定義することなくそのまま利用できます。

Answer 6

戦略パターンまたは 'ラッパー'が最適です。そして、私はJuanSánchezのソリューションがBabibuのソリューションよりも優れていると思う。 Babibuのコードのように、クラスAはDに依存してはいけません。 あなたのコードでは、クラスAにいくつかの属性が含まれていたり、クラスCが必要としないアクションがいくつかある場合は、以下のようにコードをリファクタリングすることができます。それ以外の場合、Juanの解決策で十分です。 は、私はこのような状況のためのUMLの画像を描画したが、私は コードは次のようである:-(それを投稿するには、no十分な評判をしましたしない：あなたドンすることができますように

interface IAction 
{ 
    public void actionA(); 
} 

class A extends B implements IAction 
{ 
    private IAction action; 
    public void actionA() { 
     action.actionA(); 
    } 
} 

class C extends FragmentActivity implements IAction 
{ 
    private IAction action; 
    public void actionA() { 
     action.actionA(); 
    } 
} 

class D implements IAction 
{ 
    public void actionA() { 
    // put implementation here 
    } 
} 

Answer 7

は限り継承を取り除きますクラス継承は、ほとんど常に悪い考えです。特に、実装の将来の変更が多く期待される場合は、実際には必要なのは、あまり設計されていないフレームワークで基底クラスを拡張する必要がある場合です。

Gammaらの古いデザインパターンを読むとき、C++とPascalがOOの主要言語である世界のために書かれたことに注意してください。それらの言語のどちらも持っていなかった新規性（インタフェース）を改めました。だから、実装の多くの用途を精神的に置き換えるべきであり、より良いコードに終わるでしょう。

基本的には、オブジェクト指向設計では、コヒーレンスを高く保ち、カップリングを低くすることが良いアイデアです。クラスの継承は、結合性の低いクラス（1つのクラスでは無関係な機能がたくさんあります）に簡単につながります。その理由は、基本クラスが、すべてのサブクラスや、一部のクラスにのみ関連するコードパスでは不要な機能を持つことになります。さらに、デザインが進化するにつれて、お互いから継承し、密接に結びついたクラスがたくさんあります。個人的には、複数のレベルの継承を持つコードを処理する必要がありません。それは読みにくく、継承のセマンティクスはテストをより苦痛にさせます。私は決してインターフェイス以外のものを使用することはありません。私は90年代半ばからJavaをやっています。

@この理由から、Babibuによる構成と委任の使用の方がはるかに優れています。より緊密に結合されていないより一貫性のあるクラスにつながります。メンテナンスが簡単で、再構成が簡単で、テストが容易です。