JavaRush /Java Blog /Random-IT /Patterns e Singleton: per tutti coloro che li hanno incon...

Patterns e Singleton: per tutti coloro che li hanno incontrati per la prima volta

Pubblicato nel gruppo Random-IT
Questo articolo è rivolto a coloro che per primi hanno incontrato il concetto di modello, ne hanno sentito Singletonparlare o in qualche modo lo hanno realizzato, ma non hanno ancora capito nulla. Benvenuto! Gli studenti JavaRush incontrano i pattern per la prima volta al livello 15, quando inaspettatamente il cap chiede di “correggere” e implementare un pattern Singletoncon un'implementazione lazy. Gli studenti che ne sentono parlare per la prima volta Singletonhanno immediatamente una serie di domande: cos'è uno schema, perché è necessario, che tipo di schema è Singletone, infine, che tipo di implementazione pigra è questa. Iniziamo a rispondere in ordine: Pattern e Singleton - per tutti coloro che li hanno incontrati per la prima volta - 1

Cos'è comunque uno schema?

Per una migliore comprensione, penso che valga la pena rispondere a questa domanda partendo dalla storia. Tra i programmatori ci sono quattro autori così famosi: Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides, che hanno avuto un'idea interessante.
Patterns e Singleton - per tutti coloro che li hanno incontrati per la prima volta - 2
Notarono che quando scrivevano programmi spesso dovevano risolvere più o meno gli stessi problemi e scrivere codice dello stesso tipo nella struttura. Pertanto, hanno deciso di descrivere sotto forma di modelli modelli tipici che vengono spesso utilizzati nella programmazione orientata agli oggetti. Il libro è stato pubblicato nel 1995 con il titolo “Tecniche di progettazione orientata agli oggetti. Modelli di progettazione" . Il titolo del libro si rivelò troppo lungo e divenne semplicemente noto come Il libro della banda dei quattro . Nella prima edizione furono pubblicati 23 modelli, dopodiché ne furono scoperti dozzine di altri. Quindi, rispondendo alla domanda in questo paragrafo, “Cosa sono i pattern?” , riassumiamo in poche parole:
Un modello è una soluzione standardizzata a un problema comune.
E Singletonquesto è solo uno di questi modelli.

Perché abbiamo bisogno di modelli (design pattern)

Puoi programmare senza conoscere gli schemi; puoi verificarlo semplicemente rendendoti conto del fatto che al 15° livello di JavaRush avevi scritto centinaia di mini-programmi senza sapere nulla della loro esistenza. Ciò suggerisce che un modello è una sorta di strumento, la cui presenza distingue un maestro da un dilettante:
Patterns e Singleton - per tutti coloro che li hanno incontrati per la prima volta - 3
Gli schemi descrivono come risolvere correttamente uno dei problemi tipici. Di conseguenza, conoscere i modelli ti fa risparmiare tempo. Si può fare un’analogia con gli algoritmi. Ad esempio, puoi inventare il tuo algoritmo di ordinamento con blackjack e numeri e dedicarci molto tempo, oppure puoi utilizzarne uno che è già stato descritto molto tempo fa e implementarlo. È lo stesso con i modelli. Inoltre, con l'uso dei pattern, il codice diventa più standardizzato e, utilizzando i pattern giusti, avrai meno probabilità di commettere errori, poiché erano già previsti ed eliminati in questo pattern. Bene, oltre a tutto, la conoscenza dei modelli consente ai programmatori di capirsi meglio. È sufficiente dire semplicemente il nome del modello, invece di cercare di spiegare ai tuoi colleghi programmatori cosa vuoi che facciano. Quindi, per riassumere, i design pattern aiutano:
  • non reinventare la ruota, ma utilizzare soluzioni standard;
  • standardizzare il codice;
  • standardizzare la terminologia;
In conclusione di questa sezione, notiamo che l'intera varietà di modelli può essere semplificata in tre grandi gruppi:
Pattern e Singleton - per tutti coloro che li hanno incontrati per la prima volta - 4

Finalmente un modello Singleton

Singletonsi riferisce a modelli generativi . La sua traduzione letterale è solitaria. Questo modello garantisce che una classe abbia un solo oggetto (un'istanza della classe) e che a quell'oggetto venga fornito un punto di accesso globale. Dovrebbe essere chiaro dalla descrizione che questo modello dovrebbe essere utilizzato in due casi:
  1. quando nel programma non deve essere creato più di un oggetto di qualsiasi classe. Ad esempio, in un gioco per computer hai una classe "Personaggio" e questa classe dovrebbe avere un solo oggetto che descriva il personaggio stesso.

  2. quando è necessario fornire un punto di accesso globale a un oggetto di classe. In altre parole, devi assicurarti che l'oggetto venga chiamato da qualsiasi punto del programma. E, ahimè, per questo non basta creare semplicemente una variabile globale, perché non è protetta da scrittura e chiunque può modificare il valore di questa variabile e il punto di accesso globale all'oggetto andrà perso. Queste proprietà Singletonsono necessarie, ad esempio, quando si ha un oggetto di una classe che funziona con un database ed è necessario che il database sia accessibile da diverse parti del programma. E Singletongarantirà che nessun altro codice abbia sostituito l'istanza della classe creata in precedenza.
Questi due problemi vengono risolti nel modo seguente Singleton: deve esserci un solo oggetto nel programma e deve esserci un accesso globale ad esso. Nell'esempio al livello 15, il cap chiede di implementare questo pattern per il seguente compito (ecco la sua descrizione):
Pattern e Singleton - per tutti coloro che li hanno incontrati per la prima volta - 5
Dopo aver letto attentamente la condizione, diventa chiaro il motivo per cui Singletonqui è necessario esattamente (Single). Dopotutto, il programma ti chiede di creare un oggetto di ciascuna classe: Sun, Moon, Earth. Ed è logico presumere che ogni classe del programma non debba creare più di un Sole/Luna/Terra, altrimenti sarebbe assurdo, a meno che ovviamente non si stia scrivendo la propria versione di Star Wars. Funzionalità dell'implementazione SingletonJava in tre passaggi Il comportamento singleton in Java non può essere implementato utilizzando un costruttore regolare perché il costruttore restituisce sempre un nuovo oggetto. Pertanto, tutte le implementazioni di Singleton'a si riducono a nascondere il costruttore e a creare un metodo statico pubblico che controllerà l'esistenza di un singolo oggetto e “distruggerà” tutti gli oggetti appena apparsi. Se Singletonviene chiamato 'a, deve creare un nuovo oggetto (se non è già nel programma) o restituirne uno che è già stato creato. Per fare questo: #1. – È necessario aggiungere un campo statico privato alla classe contenente un singolo oggetto:
public class LazyInitializedSingleton {
	private static LazyInitializedSingleton instance; //#1
}
#2. – Rendi privato il costruttore della classe (costruttore predefinito) (in modo che l'accesso ad esso sia chiuso all'esterno della classe, quindi non sarà in grado di restituire nuovi oggetti):
public class LazyInitializedSingleton {
	private static LazyInitializedSingleton instance;
private LazyInitializedSingleton(){} // #2
}
#3 . – Dichiarare un metodo di creazione statico che verrà utilizzato per ottenere il singleton:
public class LazyInitializedSingleton {
    private static LazyInitializedSingleton instance;
        private LazyInitializedSingleton(){}
        public static LazyInitializedSingleton getInstance(){ // #3
        if(instance == null){		//if the object has not been created yet
            instance = new LazyInitializedSingleton();	//create a new object
        }
        return instance;		// return the previously created object
    }
}
L'esempio sopra è un po' goffo, perché nascondiamo semplicemente il costruttore e forniamo il nostro metodo invece del costruttore standard. Poiché questo articolo ha lo scopo di consentire agli studenti JavaRush di entrare in contatto con questo pattern (e pattern in generale) per la prima volta, le caratteristiche di implementazione dei Singleton più complessi non verranno fornite qui. Notiamo solo che, a seconda della complessità del programma, potrebbe essere necessario un perfezionamento più dettagliato di questo modello. Ad esempio, in un ambiente multi-thread (vedi l'argomento Threads), diversi thread diversi possono chiamare contemporaneamente il metodo getter di Singleton e il codice sopra descritto smetterà di funzionare, perché ogni singolo thread sarà in grado di creare più istanze della classe subito. Pertanto, esistono ancora diversi approcci diversi per creare singleton thread-safe corretti. Ma questa è un'altra storia =) E infine. Cos'è l'inizializzazione pigra richiesta dal limite ? L'inizializzazione pigra è anche chiamata inizializzazione pigra. Si tratta di una tecnica di programmazione in cui un'operazione ad alta intensità di risorse (e la creazione di un oggetto è un'operazione ad alta intensità di risorse) viene eseguita su richiesta, anziché in anticipo. Che è fondamentalmente ciò che accade nel nostro codice Singleton'a. In altre parole, il nostro oggetto viene creato nel momento in cui si accede e non in anticipo. Non si dovrebbe dare per scontato che il concetto di inizializzazione pigra sia in qualche modo strettamente connesso con Singleton'om. L'inizializzazione pigra viene utilizzata anche in altri modelli di progettazione generativa, ad esempio in Proxy e Factory Method, ma questa è un'altra storia =) Per preparare l'articolo sono state utilizzate le seguenti fonti:
  1. Best practice per il modello di progettazione Java Singleton con esempi
  2. Modelli di progettazione
  3. Singleton corretto in Java
Commenti
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION