Perché Java enumerazioni non clonabile?

Question

E 'troppo tardi per cambiare la domanda, ma più precisa sarebbe stata quella di chiedere: "Perché il clone() non consentono single?". Un metodo copy() sarebbe più conveniente.

---

C'è qualche motivo per cui le enumerazioni in Java non possono essere clonati?

Il manuale che

Questo garantisce che le enumerazioni non sono mai clonati, che è necessario per preservare il loro status "Singleton".

Ma restituire l'istanza stessa preserverebbe anche il suo stato e sarei in grado di gestire enumerazioni associate allo stesso modo degli altri oggetti clonabili.

Si potrebbe obiettare che

L'intento generale [del clone()] è che, per qualsiasi oggetto x, l'espressione: x.clone() != x sarà vero, [...]

Ma per single, al contrario, voglio x.clone() == x per essere vero. Se l'istanza stessa fosse restituita, allora il modello singleton sarebbe trasparente agli oggetti di riferimento.

Quindi perché non è possibile clonare le enumerazioni o si è dimenticato di pensare a singleton e immutables, quando è stato specificato clone()?

Answer 1

Ma per single, al contrario, voglio x.clone() == x per essere vero.

È potrebbe voler, ma penso che sia strano che il seguente codice si spezzasse:

interface Foo extends Cloneable { public int getX(); public void setX(int x); } 
enum FooSingleton implements Foo { 
    INSTANCE; 
    private int x; 
    public int getX(){ return x; } 
    public void setX(int x){ this.x = x; } 
} 
class FooClass implements Foo { 
    private int x; 
    public int getX(){ return x; } 
    public void setX(int x){ this.x = x; } 
} 

boolean omg(Foo f){ 
    Foo c = f.clone(); 
    c.setX(c.getX() + 1); 
    return c.getX() != f.getX(); 
} 
assert omg(new FooClass());  // OK 
assert omg(FooSingleton.INSTANCE); // WTF? 

(Naturalmente, poiché clone() dà solo copie poco profonde, anche una corretta attuazione di esso può causa errori nel codice sopra.)

D'altra parte, posso essere d'accordo sul fatto che avrebbe senso per le operazioni di clonazione a solo return this per gli oggetti immutabili, e le enumerazioni dovrebbero essere immutabili. Ora, quando è stato scritto il contratto per clone(), a quanto pare non pensavano agli immutabili, o non volevano un caso speciale per un concetto che non è supportato dal linguaggio (cioè tipi immutabili).

E così, clone() è quello che è, e non si può andare molto bene e cambiare qualcosa che è stato intorno da Java 1.0. Sono abbastanza sicuro che da qualche parte là fuori, c'è un codice che si basa interamente su clone() restituendo un nuovo oggetto distinto, forse come una chiave per uno IdentityHashMap o qualcosa del genere.

Answer 2

immagino che non volevano per il trattamento di single come un caso speciale quando è stato specificato clone(). Ciò avrebbe complicato le specifiche. Così ora gli sviluppatori della libreria devono trattarli come un caso speciale, ma per il resto di noi, è bello che possiamo avere fiducia che x.clone() != x.

Answer 3

Se il metodo clone restituisce l'istanza this anziché un oggetto distinto, non è un clone, vero?

The Javadoc dice:

Per convenzione, l'oggetto restituito da questo metodo dovrebbe essere indipendente questo oggetto (che viene clonato).

Le enumerazioni non dovrebbero essere clonate perché si suppone che ci sia sempre un'istanza di ciascun valore.

EDIT: In risposta al seguente commento:

Questo è esattamente quello che critico. Perché non restituire lo stesso esempio, se ci non può essere uno diverso?

Perché non ha molto senso. Se si tratta dello stesso oggetto, allora non è un clone.Il Javadocs anche dire:

L'intento generale è che, per ogni oggetto x, l'espressione:

x.clone() != x

sarà vero, e che il espressione:

x.clone().getClass() == x.getClass()

sarà vero, ma questi non sono requisiti assoluti .

Quindi l'intento è per il metodo clone() restituire un oggetto distinto. Sfortunatamente dice che non è un requisito assoluto, il che rende valido il tuo suggerimento, ma continuo a pensare che non sia ragionevole perché non è utile avere un metodo clone che restituisce this. Potrebbe anche causare problemi se si stesse facendo qualcosa di dubbioso come avere uno stato mutabile nelle costanti enumerate o sincronizzarsi su di essi. Il comportamento di tale codice sarebbe diverso a seconda che il metodo clone abbia fatto la corretta clonazione o appena restituito this.

In realtà non si spiega perché si desidera trattare le enumerazioni come Cloneable quando sono intrinsecamente non-clonabili. Voler avere un metodo clone che non obbedisce alle convenzioni accettate sembra un trucco per risolvere un problema più fondamentale con il tuo approccio.

Answer 4

Qual è lo scopo della clonazione di un singleton, se x.clone() == x? Non puoi semplicemente usare x subito.

A rigor di termini, se si desidera clonare qualcosa e far rispettare x.clone() == x, l'unico oggetto che può essere il risultato del clone è x stessa:

def clone() { 
    return this; 
} 

che può essere fuorviante ...

---

Se si progetta qualcosa e si basano su clone() per la differenziazione, si sta facendo IMHO sbagliato ...

Answer 5

La tua risposta alla tua domanda è la migliore. In generale, la gente si aspetta che clone() restituisca un oggetto diverso. La semantica di Cloneable ha più senso in questo modo. ("L'oggetto è clonabile ... oh, devo essere in grado di fare copie.") Non riesco a pensare a una situazione off-line dove ciò è importante, ma quello era il significato semantico previsto di Cloneable.

Penso che anche se pensassero ai singleton, non l'avrebbero cambiato. Dopotutto, è responsabilità del programmatore decidere cosa può essere clonato e cosa no, aggiungendo (e potenzialmente sovrascrivendo) in modo selettivo l'interfaccia Cloneable e la maggior parte dei programmatori non aggiungerà l'interfaccia Cloneable ai singleton.

Answer 6

Ma per singleton al contrario voglio che sia x.clone() == x vero.

No, non sarebbe un clone. Così, per single, si desidera che questo:

public Object clone() throws CloneNotSupportedException { 
    throw new CloneNotSupportedException(); 
}