Modello di progettazione di Singleton e prevenzione della clonazione

Question

Molti articoli che ho letto in Rete sul modello di progettazione Singleton menzionano che la classe dovrebbe sovrascrivere il metodo 'clone()' e al suo interno lanciare l'eccezione 'CloneNotSupported'. E 'davvero necessario?

Il metodo clone() per impostazione predefinita è protetto, quindi nessuna classe (eccetto quelle nello stesso pacchetto) sarà in grado di chiamarla su quell'istanza Singleton. Inoltre, se questo Singleton non implementa Cloneable, anche se questo metodo viene chiamato, darà un'eccezione di runtime. Inoltre, essendo il costruttore privato, non saremo in grado di suddividerlo e quindi consentirne la clonazione. Quindi dovrei ancora implementare questo consiglio per le mie lezioni Singleton?

EDIT: Giusto per chiarire: non sto cercando il modo migliore per implementare Singleton. Sto solo chiedendo la validità del consiglio di cui sopra, w.r.t il normale modello Singleton (e non Singleton basato su Enum).

Answer 1

Se hai intenzione di implementare un singleton, use a one-element enum e smettere di pensarci.

---

EDIT: Giusto per chiarire: non sto cercando il modo migliore per implementare Singleton. Sto solo chiedendo la validità del consiglio di cui sopra, w.r.t il normale modello Singleton (e non Singleton basato su Enum).

Dal momento che hai Effective Java, allora si dovrebbe già essere a conoscenza delle insidie ​​e problemi con Cloneable. Detto questo, se hai intenzione di implementare un singleton uno dei modi "sbagliati", no, non c'è assolutamente alcun motivo per implementare Cloneable e sovrascrivere Object#clone() solo per lanciare CloneNotSupportedException. Object#clone() fa già questo quando l'interfaccia Cloneable è assente.

Answer 2

Vedere https://stackoverflow.com/a/71399/385478 per il modo più sicuro per applicare il modello Singleton. In sostanza, rendere Singleton un enum piuttosto che uno class, con un singolo valore INSTANCE.

Answer 3

Quando si scrive una classe utilizzando il modello Singleton, solo una istanza di classe può esistere alla volta. Di conseguenza, la classe non deve essere autorizzata a creare un clone.

Il modello singleton dice che esiste solo una istanza della classe all'interno del programma, quindi è giusto aumentare CloneNotSupportedException nel metodo Clone().

Answer 4

È necessario eseguire l'override del metodo clone() solo se la classe singleton implementa l'interfaccia Cloneable o una classe che implementa l'interfaccia Cloneable.

Answer 5

È necessario se la classe Singleton estende una classe che ha un metodo clone() visibile definito nella relativa gerarchia.

Answer 6

@ shrini1000, avete una domanda valida, ma la suggetsion circa clone è molto specifico per condizione seguente

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

Quanto sopra è necessario solo se la superclasse di una classe Singleton implementa un clone pubblico() metodo.

Answer 7

È possibile evitare la clonazione assegnando l'oggetto già creato con il metodo clone.

public Object clone() { 

return singletoneObject; 

} 

Answer 8

Il codice qui sotto è per prevenire la classe Singleton essere cloned.Override il metodo clone e gettare nuova CloneNotSupportedException()

public final class SingeltonCloneTest implements Cloneable { 

    /** 
    * @param args 
    * @return 
    */ 
    private static SingeltonCloneTest instance = null; 

    private SingeltonCloneTest() { 
    System.out.println("Rahul Tripathi"); 
    } 

    public static SingeltonCloneTest getInstance() { 

     if (instance == null) { 
      instance = new SingeltonCloneTest(); 
      return instance; 
     } 
     return instance; 
    } 

    @Override 
    protected Object clone() throws CloneNotSupportedException { 

     // TODO Auto-generated method stub 
     /* 
     * Here forcibly throws the exception for preventing to be cloned 
     */ 
     throw new CloneNotSupportedException(); 
     // return super.clone(); 
    } 

    public static void main(String[] args) { 
     // TODO Auto-generated method stub 
     SingeltonCloneTest test1 = SingeltonCloneTest.getInstance(); 

     try { 
      SingeltonCloneTest test2 = (SingeltonCloneTest) test1.clone(); 
     } catch (CloneNotSupportedException e) { 
      // TODO Auto-generated catch block 
      e.printStackTrace(); 
     } 
    } 

} 

Answer 9

L'esempio migliore che ho trovato è questo:

class SingletonSuper implements Cloneable { 
    public Object clone() throws CloneNotSupportedException { 
     return super.clone(); 
    } 
} 

class Singleton2 extends SingletonSuper { 
    // 1. Make all constructors private 
    private Singleton2() { 
    } 

// 2. Declare a private static variable to hold single instance of class 
    private static Singleton2 INSTANCE = new Singleton2(); 

    public static Singleton2 getInstance() { 
     return INSTANCE; 
    } 
    } 

public class SingletonCloningTest { 
    public static void main(String[] args) throws Exception { 
     System.out.println("Singleton Test!"); 
     System.out.println("Singleton Instance:" +       + Singleton2.getInstance()); 
     System.out.println("Singleton clone:" 
      + Singleton2.getInstance().clone()); 
    } 
} 



The result will: 

Singleton Test! 
Singleton Instance:com.sample.test.Singleton2@50d89c 
Singleton clone:com.sample.test.Singleton2@1bd0dd4 

Answer 10

Secondo la mia comprensione non è necessario implementare il metodo clone(). Motivo: 1. Se non si implementa il metodo clone e l'interfaccia Cloneable, verrà generata l'eccezione CloneNotSupportedException. 2. il metodo clone è protetto e non è possibile sottoclasse una classe singleton.

Answer 11

Sovrascrivere il metodo clone() implementando l'interfaccia Cloneable e lanciare CloneNotSupportedException();

@Override 
protected Object clone() throws CloneNotSupportedException { 
    // directly throw Clone Not Supported Exception 
    throw new CloneNotSupportedException(); 
}  

Per i dettagli sulla limitazione a 4 vie della creazione di oggetti in Java, leggere qui http://www.benchresources.net/singleton-design-pattern-restricting-all-4-ways-of-object-creation-in-java/