Javaで、実装クラスの引数を受け取るメソッドを持つインターフェースを定義することはできますか?
インターフェース:
public interface MyInterface {
public <T is/extends of the type of the implementing class> void method(T object);
}
クラス:
public class A implements MyInterface {
public void method(A object) {
...
}
}
私が避けたいのは、クラスがそれ自体のような別のクラスで MyInterface を実装できることです。
したがって、これは許可されるべきではありません:
public class A implements MyInterface<B> {
public void method(B object) {
...
}
}
編集:
わかりました、私が達成したいことを別の方法で説明しようとします。そのタイプのクラスの引数を受け入れるメソッドを持ついくつかのクラスが必要です。したがって、上記のクラス A に加えて、次のような別のクラス B があるとします。
public class B implements MyInterface {
public void method(B object) {
...
}
}
ブース クラス A と B に共通するのは、クラス自体の型の引数を受け取る「メソッド」と呼ばれるメソッドです。
私のプロジェクトでは、次のことを達成したいと考えています。私は小さなゲームを書いており、ある種の衝突検出を実装したいと考えています。基本的に、「スマートな」ポリモーフィスティック呼び出しを行うことでこれを行いたいと考えています。
次のようなインターフェイス ICollisionReceiver を定義しました。
public interface ICollisionReceiver<T extends IShape> extends IShape {
public boolean collides(T t);
}
そして、次のような別のインターフェースを定義しました:
public interface ICollisionChecker<T extends ICollisionChecker<T>> extends IShape {
public void addCollisionReceiver(ICollisionReceiver<T> receiver);
public void removeCollisionReceiver(ICollisionReceiver<T> receiver);
}
たとえば、私のプレーヤーは、衝突を受け取って処理するときに ICollisionReceiver インターフェイスを実装します。これは一般的な方法で行う必要があるため、たとえば、ボックスとサークルがあり、Player は ICollisionReceiver < Box > と ICollisionReceiver < Circle > を実装しているため、両方のメソッドがあります。
@Override
public boolean collides(final Box b) {
...
return false;
}
と
@Override
public boolean collides(final Circle c) {
...
return false;
}
私のボックスとサークル クラスでは、ICollisionReceivers を登録できます。次に、update メソッドで次のことを行います。
boolean conti = true;
int i=0;
while(conti && i<collisionReceivers.size()) {
final ICollisionReceiver<Bonus> rec = collisionReceivers.get(i);
if(this.collidesWith(rec)) {
conti = rec.collides(this);
}
++i;
}
これは基本的に、このボックスが特定のレシーバーと衝突するかどうかをチェックし、レシーバーのcollides()メソッドを呼び出します。
要点は、クラス box と circle の両方が ICollisionChecker インターフェイスを独自の型でのみ実装することを確認したいということです。
このようなことを行うことで、明示的にこれを行うことができます
public class Bonus extends AnimatedSprite implements ICollisionChecker<Bonus>...
しかし、これは私にとって非常に満足のいくものではありません...
長い投稿で申し訳ありませんが、これで明確になることを願っています。