3

このようなインターフェイスを作成し、変数がクローン可能であることを確認する必要がある場所でそれを使用することについて何か悪いことや間違っていることはありますか?

public interface PublicCloneable<I> {
    public I clone();
}

これは、Java の Cloneable インターフェイスが壊れているという事実に関連する SO の質問であり、なぜこのように実装されていないのか理解できません。

4

3 に答える 3

2

あなたはできる。新しいインターフェイスを作成する際の主な問題は、このインターフェイスを明示的に実装する、作成した新しいクラスでのみこのインターフェイスを使用できることです。Java ライブラリの既存のクラスは、コードを変更できないため、このインターフェイスを実装できません。(インターフェイスは魔法のように既存の型に適用されるわけではありません。) したがって、使用する予定のすべてのオブジェクトに対してカスタム クラスのファミリを作成し、標準ライブラリ クラスを使用しない場合にのみ役立ちます。

于 2011-07-17T22:19:10.057 に答える
1

これは問題ありませんが、メソッド内に独自の複製ロジックを提供する必要があります。

の考え方はjava.lang.Cloneable、クラスを複製可能としてマークし、複製ロジックを JVM で処理することです。フィールドごとのクローン作成を提供しませんObject.clone()

この回答で提案されているものから、別の複製メカニズムを選択できます (または、インターフェイスを別のメカニズムと組み合わせて使用​​できます) 。

于 2011-07-17T20:00:31.253 に答える
1

完全に独自の実装を使用したい場合は、clone()問題ありません。ただし、ある時点で Object.clone() を使用する場合は、お勧めします

public interface PublicCloneable<I> extends Cloneable {
    public I clone();
}

および内部実装:

   public static class MyClass implements PublicCloneable<MyClass> {
     public MyClass clone() {
        try {
            return (MyClass)super.clone(); // Or do whatever you need here
        } catch (CloneNotSupportedException e) {
            // Always supported
        }
   }

コンパイルできるかどうかはわかりませんでしたが、試してみたところ、問題ないようです。

もちろん、走行距離は異なる場合があります。

于 2011-07-17T20:09:50.210 に答える