0

次のようなものがあるとしましょう。

public abstract class MyClass {
    //Stuff in here
}

public class MyClassA extends MyClass {

    private String thingie; //Along with getter/setters, of course
    //Other stuff
}

public class MyClassB extends MyClass {

    private List<Integer> thingies; //Again, getters and setters to go with
    //Other stuff
}

MyClass を拡張する任意の数のクラスがあり、それぞれが異なる型の独自のインスタンス変数を持ちますが、同じ型を持つものもあると仮定しましょう。これは残念ながら必要なことです。ここで、MyClass の Collection があるとします。任意の数の子クラスで満たされたコレクションがあり、それぞれにオブジェクトが含まれています。この Collection を反復処理し、任意の数の要素からオブジェクトを取得し、それに対してアクションを実行し、保存し、操作し、別の場所に送信する必要があるとします。これらのオブジェクトには、Object の拡張以外に共通点はありません。

これらのアクションを MyClass の子自体に委任したり、ビジターを使用したりすることは簡単にできるかもしれませんが、これらのアクションはコレクション内の他の MyClass の子に依存している可能性があるため、これはおそらく実現不可能です。単一の MyClass の子は、それ自体で、または MyClass の任意の単一のコレクションでさえも実行されるアクションを決定することはありません。これらのアクションの一部は累積的であり、他の多くの潜在的な累積要因に依存している可能性があります。

これを処理する「良い」方法はありますか、それとも醜い型チェック条件または同様のものの地獄に呪われるだけですか? MyClass で Generics を使用し、すべての子で具象型を使用することを検討しました。これにより、オブジェクトの取得が簡素化される可能性がありますが、それでも大きな条件付きブロックが必要になります。

4

1 に答える 1

0

あなたは質問でそれを行う「良い」方法を破棄しました。この場合、ジェネリックは役に立ちません。はい、型チェックの醜い使用のために厄介な場所に呪われることになります。categoryたとえば、と呼ばれる共通のインスタンス メンバーとgetCategory、MyClass. そして、彼らは(複数の sswitchではなく) で if you can を実行します。ただし、タイプをチェックしているかどうかに関係なく、あなたを非難する人はs を嫌う可能性があります。また、彼らは頭が良く、あなたが何をしようとしているのかを理解している可能性もあります。何でもないifgetCategory()ifswitches

for(MyClass e: collection )
    e.doYourAction();

悪い"。

さて、仕様がまったくないように見えるソフトウェアについては、ご容赦ください。

于 2013-08-26T21:59:30.033 に答える