基本クラスがありBaseます。2つのサブクラスとがSub1ありSub2ます。各サブクラスにはいくつかの追加メソッドがあります。たとえば、Sub1has Sandwich makeASandwich(Ingredients... ingredients)、およびSub2has boolean contactAliens(Frequency onFrequency)。

これらのメソッドは異なるパラメーターを取り、まったく異なることを行うため、完全に互換性がなく、この問題を解決するためにポリモーフィズムを使用することはできません。

Baseほとんどの機能を提供し、Baseオブジェクトの大規模なコレクションを持っています。ただし、すべてのBaseオブジェクトはa Sub1またはaのいずれかSub2であり、時にはそれらがどれであるかを知る必要があります。

次のことを行うのは悪い考えのようです。

for (Base base : bases) {
    if (base instanceof Sub1) {
        ((Sub1) base).makeASandwich(getRandomIngredients());
        // ... etc.
    } else { // must be Sub2
        ((Sub2) base).contactAliens(getFrequency());
        // ... etc.
    }
}

そこで、キャストせずにこれを回避する戦略を思いつきました。 Base現在、これらのメソッドがあります：

boolean isSub1();
Sub1 asSub1();
Sub2 asSub2();

そしてもちろん、Sub1これらのメソッドを次のように実装します

boolean isSub1() { return true; }
Sub1 asSub1();   { return this; }
Sub2 asSub2();   { throw new IllegalStateException(); }

そして、Sub2それらを逆の方法で実装します。

残念ながら、現在Sub1、Sub2これらのメソッドは独自のAPIにあります。そのため、たとえばでこれを行うことができますSub1。

/** no need to use this if object is known to be Sub1 */
@Deprecated
boolean isSub1() { return true; }

/** no need to use this if object is known to be Sub1 */
@Deprecated
Sub1 asSub1();   { return this; }

/** no need to use this if object is known to be Sub1 */
@Deprecated
Sub2 asSub2();   { throw new IllegalStateException(); }

このように、オブジェクトがaのみであることがわかっている場合Base、これらのメソッドは非推奨ではなく、サブクラスのメソッドを呼び出すために別の型に「キャスト」するために使用できます。これはある意味ではエレガントに思えますが、一方で、クラスからメソッドを「削除」する方法としてDeprecatedアノテーションを悪用しています。

以来Sub1インスタンスが本当にあるベース、それは使用の継承ではなく、カプセル化にメイクセンスを行います。私がやっていることは良いですか？この問題を解決するより良い方法はありますか？

他のいくつかの回答で提案されているように、基本クラスに関数を追加することは必ずしも意味がありません。追加する特殊なケース関数が多すぎると、それ以外の場合は無関係なコンポーネントが結合される可能性があります。

たとえばAnimal、CatとDogコンポーネントを持つクラスがあります。それらを印刷したり、GUIで表示したい場合は、基本クラスに追加しrenderToGUI(...)たり追加したりsendToPrinter(...)するのはやり過ぎかもしれません。

型チェックとキャストを使用しているアプローチは脆弱ですが、少なくとも懸念事項は分離されています。

ただし、これらのタイプのチェック/キャストを頻繁に実行している場合は、ビジター/ダブルディスパッチパターンを実装することが1つのオプションです。次のように見えます：

public abstract class Base {
  ...
  abstract void visit( BaseVisitor visitor );
}

public class Sub1 extends Base {
  ...
  void visit(BaseVisitor visitor) { visitor.onSub1(this); }
}

public class Sub2 extends Base {
  ...
  void visit(BaseVisitor visitor) { visitor.onSub2(this); }
}

public interface BaseVisitor {
   void onSub1(Sub1 that);
   void onSub2(Sub2 that);
}

これであなたのコードは

public class ActOnBase implements BaseVisitor {
    void onSub1(Sub1 that) {
       that.makeASandwich(getRandomIngredients())
    }

    void onSub2(Sub2 that) {
       that.contactAliens(getFrequency());
    }
}

BaseVisitor visitor = new ActOnBase();
for (Base base : bases) {
    base.visit(visitor);
}

主な利点は、サブクラスを追加すると、静かに欠落しているケースではなく、コンパイルエラーが発生することです。新しいビジタークラスは、関数をプルするための素晴らしいターゲットにもなります。例えば、それは移動しても意味がありますgetRandomIngredients()にActOnBase。

ループロジックを抽出することもできます。たとえば、上記のフラグメントは次のようになります。

BaseVisitor.applyToArray(bases, new ActOnBase() );

さらに少しマッサージして、Java 8のラムダとストリーミングを使用すると、

bases.stream()
     .forEach( BaseVisitor.forEach(
       Sub1 that -> that.makeASandwich(getRandomIngredients()),
       Sub2 that -> that.contactAliens(getFrequency())
     ));

どのIMOが、見た目も簡潔で、あなたが手に入れることができるのと同じくらい簡潔です。

次に、より完全なJava 8の例を示します。

public static abstract class Base {
    abstract void visit( BaseVisitor visitor );
}

public static class Sub1 extends Base {
    void visit(BaseVisitor visitor) { visitor.onSub1(this); }

    void makeASandwich() {
        System.out.println("making a sandwich");
    }
}

public static class Sub2 extends Base {
    void visit(BaseVisitor visitor) { visitor.onSub2(this); }

    void contactAliens() {
        System.out.println("contacting aliens");
    }
}

public interface BaseVisitor {
    void onSub1(Sub1 that);
    void onSub2(Sub2 that);

    static Consumer<Base> forEach(Consumer<Sub1> sub1, Consumer<Sub2> sub2) {

        return base -> {
            BaseVisitor baseVisitor = new BaseVisitor() {

                @Override
                public void onSub1(Sub1 that) {
                    sub1.accept(that);
                }

                @Override
                public void onSub2(Sub2 that) {
                    sub2.accept(that);
                }
            };
            base.visit(baseVisitor);
        };
    }
}

Collection<Base> bases = Arrays.asList(new Sub1(), new Sub2());

bases.stream()
     .forEach(BaseVisitor.forEach(
             Sub1::makeASandwich,
             Sub2::contactAliens));

私の観点から：あなたのデザインが間違っています。

自然言語に翻訳すると、あなたは次のことを言っています：

我々が持っていることを考えるとanimals、がcatsありfishます。 およびにanimals共通のプロパティがcatsありfishます。しかし、それだけでは十分ではありません。いくつかのプロパティがあり、これらはcatから区別されるfishため、サブクラス化する必要があります。

これで、運動のモデル化を忘れたという問題があります。はい。それは比較的簡単です：

for(Animal a : animals){
   if (a instanceof Fish) swim();
   if (a instanceof Cat) walk();
}

しかし、それは間違った設計です。正しい方法は次のとおりです。

for(Animal a : animals){
    animal.move()
}

move共有行動は、各動物によって異なる場所で実装されます。

これらのメソッドは異なるパラメーターを取り、まったく異なることを行うため、完全に互換性がなく、この問題を解決するためにポリモーフィズムを使用することはできません。

つまり、デザインが壊れています。

私の推奨事項：リファクタリングBase、Sub1およびSub2。

あなたが物事のグループを持っている状況を想像するのは少し難しいです。このようなキャストを見つけるほとんどの場合、1つのタイプで操作します。たとえば、clang では、リスト内のノードごとに異なる処理を行うのではなく、getAsFunctionがnull以外を返す宣言のノードセットをフィルタリングします。

アクションのシーケンスを実行する必要があるかもしれませんが、アクションを実行するオブジェクトが関連していることは実際には関係ありません。

のリストの代わりに、Baseアクションのリストを処理します

for (RandomAction action : actions)
   action.act(context);

どこで

interface RandomAction {
    void act(Context context);
} 

interface Context {
    Ingredients getRandomIngredients();
    double getFrequency();
}

必要に応じて、Baseにアクションを返すメソッドを実装させるか、ベースリスト内のインスタンスからアクションを選択する必要がある他の手段を実行できます（ポリモーフィズムを使用できないと言うので、おそらく実行するアクションはクラスの関数ではなく、基底の他のプロパティです;それ以外の場合は、Baseにact（Context）メソッドを渡します）

サブクラスで実行できることを定義する1つ以上のインターフェイスを実装している場合はどうでしょうか。このようなもの：

interface SandwichCook
{
    public void makeASandwich(String[] ingredients);
}

interface AlienRadioSignalAwarable
{
    public void contactAliens(int frequency);

}

クラスは次のようになります。

class Sub1 extends Base implements SandwichCook
{
    public void makeASandwich(String[] ingredients)
    {
        //some code here
    }
}

class Sub2 extends Base implements AlienRadioSignalAwarable
{
    public void contactAliens(int frequency)
    {
        //some code here
    }
}

そして、forループは次のようになります。

for (Base base : bases) {
    if (base instanceof SandwichCook) {
        base.makeASandwich(getRandomIngredients());
    } else if (base instanceof AlienRadioSignalAwarable) {
        base.contactAliens(getFrequency());
    }
}

このアプローチの2つの主な利点：

• キャストなし
• 各サブクラスに必要な数のインターフェイスを実装させることができます。これにより、将来の変更に対してある程度の柔軟性が提供されます。

PS：インターフェースの名前についてすみません、その特定の瞬間にもっとクールなものは考えられませんでした：D。

アプローチは、ファミリー内のほぼすべてのタイプであろう場合には良いものとすることができるいずれかのいくつかの基準を満たすいくつかのインターフェースの実装として直接使用すること、またはそのインターフェースの実装を作成するために使用することができます。組み込みのコレクションタイプはこのパターンの恩恵を受けましたが、例の目的ではないため、コレクションインターフェイスを発明しますBunchOfThings<T>。

の一部の実装BunchOfThingsは変更可能です。いくつかはそうではありません。多くの場合、オブジェクトFredはaとして使用できるものを保持しBunchOfThings、Fred以外は何も変更できないことを知りたい場合があります。この要件は、次の2つの方法で満たすことができます。

1. フレッドは、それへの唯一の参照を保持し、その内部BunchOfThingsへの外部参照BunchOfThingsは宇宙のどこにも存在しないことを知っています。他の誰もBunchOfThingsまたはその内部への参照を持たない場合、他の誰もそれを変更できないため、制約は満たされます。

2. BunchOfThings、および外部参照が存在する内部のいずれも、いかなる手段でも変更できません。絶対に誰もaを変更できない場合BunchOfThings、制約は満たされます。

制約を満たす1つの方法は、受け取ったオブジェクトを無条件にコピーすることです（ネストされたコンポーネントを再帰的に処理します）。もう1つは、受け取ったオブジェクトが不変性を保証するかどうかをテストし、そうでない場合はそのコピーを作成し、ネストされたコンポーネントで同様に行うことです。2番目よりもクリーンで、1番目よりも高速になりがちな代替AsImmutable方法は、オブジェクトにそれ自体の不変コピーを作成するように要求するメソッドを提供することです（それAsImmutableをサポートするネストされたコンポーネントを使用）。

関連するメソッドも提供される場合がありますasDetached（コードがオブジェクトを受け取り、それを変更するかどうかわからない場合に使用します。その場合、変更可能なオブジェクトを新しい変更可能なオブジェクトに置き換える必要がありますが、不変のオブジェクトは保持できます）そのまま）、asMutable（オブジェクトが以前に返されたオブジェクトを保持することを知っている場合asDetached、つまり、可変オブジェクトへの非共有参照または可変オブジェクトへの共有可能な参照）、およびasNewMutable（コードが外部を受信する場合）参照し、その中のデータのコピーを変更したいことを知っています。着信データが変更可能な場合、変更可能なコピーを作成するためにすぐに使用されてから破棄される不変のコピーを作成することから始める理由はありません）

一方でことに注意してくださいasXX方法は若干異なる種類を返すことがあり、彼らの本当の役割は、返されるオブジェクトは、プログラムのニーズを満たすことを確認することです。

あなたが良いデザインを持っているかどうかの問題を無視し、それが良いか少なくとも受け入れられると仮定すると、タイプではなくサブクラスの機能を検討したいと思います。

したがって、次のいずれかです。

基本クラスの一部のインスタンスではできないことを知っていても、サンドイッチとエイリアンの存在に関する知識を基本クラスに移動します。基本クラスに実装して例外をスローし、コードを次のように変更します。

if (base.canMakeASandwich()) {
    base.makeASandwich(getRandomIngredients());
    // ... etc.
} else { // can't make sandwiches, must be able to contact aliens
    base.contactAliens(getFrequency());
    // ... etc.
}

次に、1つまたは両方のサブクラスがオーバーライドしcanMakeASandwich()、1つだけがmakeASandwich()とのそれぞれを実装しcontactAliens()ます。

型が持つ機能を検出するには、具体的なサブクラスではなくインターフェイスを使用します。基本クラスをそのままにして、コードを次のように変更します。

if (base instanceof SandwichMaker) {
    ((SandwichMaker)base).makeASandwich(getRandomIngredients());
    // ... etc.
} else { // can't make sandwiches, must be able to contact aliens
    ((AlienContacter)base).contactAliens(getFrequency());
    // ... etc.
}

または場合によっては（そして、このオプションがあなたのスタイルに合わない場合、あるいはあなたが賢明だと思うJavaスタイルについては、このオプションを無視しても構いません）：

try {
    ((SandwichMaker)base).makeASandwich(getRandomIngredients());
} catch (ClassCastException e) {
    ((AlienContacter)base).contactAliens(getFrequency());
}

個人的に私はそうではない通常ので不適切引くのリスクを、半予想例外をキャッチする後者のスタイルのようにClassCastException出てくるのgetRandomIngredientsかmakeASandwichが、メーリングリストへ。

ここに、派生クラスにダウンキャストする基本クラスの興味深いケースがあります。これは通常良くないことを十分に知っていますが、正当な理由が見つかったと言いたい場合は、これに対する制約が何であるかを見てみましょう。

1. 基本クラスのすべてのケースをカバーできます。
2. 外部派生クラスは、新しいケースを追加する必要がありません。
3. 基本クラスの制御下にある呼び出しを行うポリシーを使用できます。
4. しかし、私たちの科学から、基本クラスにないメソッドの派生クラスで何をすべきかというポリシーは、派生クラスのポリシーであり、基本クラスではないことがわかっています。

4の場合、次のようになります。5.派生クラスのポリシーは、基本クラスのポリシーと常に同じ政治的管理下にあります。

2と5は両方とも、すべての派生クラスを列挙できることを直接意味します。つまり、外部派生クラスは存在しないはずです。

しかし、ここにあります。それらがすべてあなたのものであれば、ifを仮想メソッド呼び出しである抽象化に置き換えて（それがナンセンスな呼び出しであっても）、ifとセルフキャストを取り除くことができます。したがって、それをしないでください。より良いデザインが利用可能です。

Sub1で1つのこと、Sub2で別のことを行う抽象メソッドを基本クラスに配置し、混合ループでその抽象メソッドを呼び出します。

class Sub1 : Base {
    @Override void doAThing() {
        this.makeASandwich(getRandomIngredients());
    }
}

class Sub2 : Base {
    @Override void doAThing() {
        this.contactAliens(getFrequency());
    }
}

for (Base base : bases) {
    base.doAThing();
}

getRandomIngredientsとgetFrequencyの定義方法によっては、これに他の変更が必要になる場合があることに注意してください。しかし、正直なところ、とにかくgetFrequencyを定義するには、おそらく、エイリアンに接触するクラス内がより良い場所です。

ちなみに、asSub1メソッドとasSub2メソッドは間違いなく悪い習慣です。これを行う場合は、キャストしてください。これらのメソッドが、キャストでは得られないものは何もありません。

両方makeASandwichをcontactAliens基本クラスにプッシュしてから、それらをダミー実装で実装できます。戻り値の型/引数は共通の基本クラスに解決できないため。

class Sub1 extends Base{
    Sandwich makeASandwich(Ingredients i){
        //Normal implementation
    }
    boolean contactAliens(Frequency onFrequency){
        return false;
    }
 }
class Sub2 extends Base{
    Sandwich makeASandwich(Ingredients i){
        return null;
    }
    boolean contactAliens(Frequency onFrequency){
       // normal implementation
    }
 }

この種のことには明らかな欠点があります。それはメソッドのコントラクトにとって何を意味するのか、結果のコンテキストについて何を推論できるのか、できないのかなどです。サンドイッチを作れなかったので、試食などで材料が使い果たされたとは思えません。

あなたがしていることは完全に合法です。彼らはいくつかの本でそれを読んだので、単に教義を繰り返している否定論者に注意を払ってはいけません。ドグマにはエンジニアリングの場がありません。

私は同じメカニズムを数回使用しましたが、Javaランタイムも、考えられる少なくとも1つの場所で同じことを実行できたため、パフォーマンス、使いやすさ、コードの可読性が向上したと確信できます。それを使用します。

例えば取るjava.lang.reflect.Memberのベースである、java.lang.reflect.Fieldとjava.lang.reflect.Method。（実際の階層はそれよりも少し複雑ですが、それは無関係です。）フィールドとメソッドは非常に異なる動物です。一方には取得または設定できる値があり、他方にはそのようなものはありませんが、多数のパラメータを使用し、値を返す場合があります。したがって、フィールドとメソッドはどちらもメンバーですが、それらを使ってできることは、サンドイッチを作ることとエイリアンに連絡することと同じくらいお互いに異なっています。

さて、リフレクションを使用するコードを書くときMember、私たちはしばしばa を手にし、それがa Methodまたはa Field（またはめったに何か他のもの）であることを知っていますが、instanceof正確に把握するためにすべての退屈な作業をしなければなりませんそれが何であるか、それをキャストして適切な参照を取得する必要があります。（また、これは退屈なだけでなく、パフォーマンスもあまりよくありません。）Methodクラスは、説明しているパターンを非常に簡単に実装できたため、何千人ものプログラマーの生活が楽になりました。

もちろん、この手法は、密接に結合されたクラスの小さく明確に定義された階層でのみ実行可能です。クラス階層が以下の場合、ソースレベルで制御します（常に保持します）。基本クラスをリファクタリングする自由がない人々によって拡張される可能性があります。

ここに私がしたこととあなたがしたこととの違いがあります：

• 基本クラスは、asDerivedClass()メソッドのファミリー全体にデフォルトの実装を提供し、それぞれがメソッドを返すようにしnullます。

• 各派生クラスは、asDerivedClass()メソッドの1つだけをオーバーライドし、thisではなくを返しますnull。残りの部分をオーバーライドすることも、それらについて何も知りたくないこともありません。したがって、IllegalStateExceptionsはスローされません。

• 基本クラスは、次のようにコード化されたメソッドファミリfinal全体の実装も提供isDerivedClass()します。return asDerivedClass() != null; この方法により、派生クラスによってオーバーライドされる必要があるメソッドの数が最小限に抑えられます。

• 私は@Deprecatedそれを考えなかったので、このメカニズムで使用していません。あなたが私にアイデアを与えたので、私はそれを使用することにします、ありがとう！

C＃には、asキーワードを使用して組み込まれた関連メカニズムがあります。C＃で言うDerivedClass derivedInstance = baseInstance as DerivedClassことができ、DerivedClassあなたbaseInstanceがそのクラスに属していた場合、そうでない場合に参照を取得しますnull。これは（理論的に）isキャストが続くよりも優れたパフォーマンスを発揮します（is確かにinstanceof、C＃キーワードの名前の方が優れていinstanceofます）。asC＃の演算子は、カスタムアプローチの単一の仮想メソッド呼び出しほど高速ではないためです。

私はここで、この手法はパターンであると宣言されるべきであり、それについていい名前が見つかるべきであるという命題を提示しました。

ジー、ダウンボートに感謝します！

コメントを読む手間を省くための論争の要約：

人々の反対は、元のデザインが間違っていたということであるようです。つまり、共通の基本クラスから派生するクラスが大きく異なることはありません。基本参照であり、派生クラスを把握する必要があります。したがって、彼らは、この質問と私の答えによって提案された、元のデザインの使用を改善する自己鋳造メカニズムは、そもそも必要ではなかったと言っています。（彼らは実際にセルフキャスティングのメカニズム自体については何も言わず、メカニズムが適用されることを意図している設計の性質についてのみ不平を言っています。）

しかし、この例では私がしている上に、すでに Javaランタイムの作成者が実際にのために正確なデザインを選んだことを示しjava.lang.reflect.Member、Field、Method階層、およびI下のコメント欄では、また、 C＃のランタイムのクリエイターが独立してANに到着したことを示しています同等の設計System.Reflection.MemberInfo、FieldInfo、MethodInfo階層。したがって、これらは2つの異なる現実世界のシナリオであり、すべての人の鼻の真下にあり、まさにそのような設計を使用した実証可能な実行可能なソリューションを備えています。

それが、以下のすべてのコメントの要約です。自己キャストのメカニズムについてはほとんど言及されていません。