共通のインターフェースを実装するクラスがたくさんあります：コマンド。
そして、このクラスの束はマップに行きます。
マップを正しく機能させるには、コマンドを実装する各クラスにObject.equals(Object other)メソッドをオーバーライドする必要があります。
大丈夫だよ。
しかし、私は等しいもののオーバーライドを強制したいと思います。=>コマンドを実装するものがequalsをオーバーライドしない場合、コンパイルエラーが発生します。
それは可能ですか？
編集：ところで、私もハッシュコードのオーバーライドを強制する必要があります...
いいえ、できません。ただし、できることは、インターフェイスの代わりに抽象基本クラスを使用して、抽象化することequals()です。
abstract class Command {
// put other methods from Command interface here
public abstract boolean equals(Object other);
public abstract int hashCode();
}
のサブクラスは、独自のequalsメソッドとhashCodeメソッドを提供するCommand 必要があります。
APIユーザーに基本クラスの拡張を強制することは一般的に悪い習慣ですが、この場合は正当化される可能性があります。また、コマンドインターフェイスに加えCommandて人工的な基本クラスを導入するのではなく、インターフェイスの代わりに抽象基本クラスを作成する場合、APIユーザーがそれを間違えるリスクはありません。
java.lang.Objectではなく抽象XObjectからオブジェクトを拡張できますか？
public abstract class XObject
extends Object
{
@Override
public abstract boolean equals(Object o);
}
孫がいる場合、その父親はすでにequalsメソッドとhashCodeメソッドの両方をオーバーライドしているため、抽象クラスは機能しません。その後、問題が再び発生します。
annotatinsとAPT（http://docs.oracle.com/javase/1.5.0/docs/guide/apt/GettingStarted.html）を使用して実行してみてください。
これは、Commandがインターフェース、または抽象クラスである場合にのみ可能です。ここで、equals（..）は抽象として宣言されたメソッドです。
問題は、すべてのオブジェクトのスーパークラスであるObjectがすでにこのメソッドを定義していることです。
これが（実行時に）問題であることを示したい場合は、例外をスローして、APIのユーザーにそれをオーバーライドさせることができます。しかし、少なくとも私の知る限り、コンパイル時には不可能です。
CommandEqualsなどのAPI固有のメソッドを使用して、この問題を回避してみてください。もう1つのオプションは、（前述のように）Equals抽象メソッドを定義する別のクラスを拡張することです。
で作成boolean myEquals()しinterface Command、次のようにアダプタを作成できます。
class MyAdapter{
Command c;
boolean equals(Object x) {
return c.myEquals((Command)x);
}
}
次に、map.put(key, new MyAdapter(command))代わりに使用しますmap.put(key, command)
interface A{
public boolean equal2(Object obj);
}
abstract class B implements A {
@Override
public boolean equals(Object obj) {
return equal2(obj);
}
}
class C extends B {
public boolean equal2(Object obj) {
throw new UnsupportedOperationException("Not supported yet.");
}
}
ランタイムチェックが必要な場合は、次のようにすることができます。
interface Foo{
}
class A implements Foo {
}
class B implements Foo {
@Override
public boolean equals(Object obj) {
return super.equals(obj);
}
}
public static void main(String[] args) {
Class<A> clazzA = A.class;
Class<B> clazzB = B.class;
Class<Object> objectClass = Object.class;
try {
Method methodFromObject = objectClass.getMethod("equals",Object.class);
Method methodFromA = clazzA.getMethod("equals",Object.class);
Method methodFromB = clazzB.getMethod("equals",Object.class);
System.out.println("Object == A" + methodFromObject.equals(methodFromA));
System.out.println("Object == B" + methodFromObject.equals(methodFromB));
} catch (SecurityException e) {
e.printStackTrace();
} catch (NoSuchMethodException e) {
e.printStackTrace();
}
}
最初のものはtrue、2番目はfalseを出力します。コンパイル時間が必要な場合は、アノテーションを作成し、アノテーション処理ツールを使用して、すべてのアノテーション付きクラスのオーバーライドが等しいことを確認するのが唯一のオプションのように見えます。
からequals()継承されObjectているので、それを強制することはできないと思います。すべてのタイプに対して、利用可能なの自動継承された実装があるからequals()です。
Objectクラスからのものであるため、equalsのオーバーライドを強制することはできないと思います。
関連する注記として、equalsをオーバーライドする場合は常に、Objectクラスの「hashCode」メソッドをオーバーライドする必要があることに注意してください。これは、クラスのインスタンスをマップのキーとして使用する場合に特に重要になります。この記事を確認してください： http ： //www.artima.com/lejava/articles/equality.htmlは、equalsを正しい方法でオーバーライドする方法に関するヒントを提供します。
他の答えがすでに説明しているように、あなたはあなたがしようとしているようなことを強制することはできません。
「十分に」機能する可能性のあるものの1つは、2番目のインターフェースを定義することです。これをMappableCommandと呼びます。
public interface MappableCommand
{
}
このインターフェースのドキュメントでは、クラス設計者があなたが述べた要件を考慮した場合にのみ、クラスがこの（空の）インターフェースを実装する必要があることを示しています。
次に、マップの値タイプをMappableCommandに設定すると、MappableCommandsのみをマップに追加できます。
これは、Javaのデフォルトのシリアル化メカニズムでシリアル化できるクラスに対して（空白の）インターフェースSerializableを実装する必要がある理由の背後にあるロジックに似ています。
これが機能しない場合は、実行時エラーをスローすることで解決する必要があるかもしれません。
偽の編集：
この要件をより明確にしたい場合は、この方法で新しいインターフェースを定義できます。
public interface MappableCommand
{
public void iOverrodeTheEqualsMethod();
public void seriouslyIPromiseThatIOverrodeIt();
}
他の提案されたソリューションのいくつかのバリエーションを次に示します。
public abstract class CommandOverridingEquals implements Command {
public abstract boolean equals(Object other);
public abstract int hashcode();
}
Map<String, CommandOverridingEquals> map =
new HashMap<String, CommandOverridingEquals>();
または、本当に確認したい場合は、チェック済みのハッシュマップを使用してください。例えば
Map<String, CommandOverridingEquals> map = Collections.checkedMap(
new HashMap<String, Command>(),
String.class, CommandOverridingEquals.class);
しかし、あなたが何をしても、誰かがこれをするのを止めることはできません：
public class AntiFascistCommand extends CommandOverridingEquals {
public boolean equals(Object other) { return super.equals(other); }
public int hashcode() { return super.hashcode(); }
...
}
こういうことでトラブルが発生するのではないかと思いがちです。たとえば、他の基本クラスを拡張し、（偶然に）規定の方法でオーバーライドする既存のコマンドクラスがたくさんあるequalsとします。hashcode問題は、それらのクラスを使用できないことです。代わりに、私はそれらを再実装するか、ラッパーの束を書くことを余儀なくされています。
IMO、開発者を特定の実装パターンに強制しようとするのは悪い考えです。Javadocにいくつかの強力な警告を入れて、開発者に正しいことを任せるほうがよいでしょう。
問題のマップに独自のものを提供することは可能java.util.comparatorですか？