singleton pattern

[mad_hhatter]

perchè si ricorre al attern singleton invece di usare una classe con soli membri statici? operativamente mi sembra la stessa cosa... o mi sfugge qualcosa?

[andbin]

Originariamente inviato da mad_hhatter

perchè si ricorre al attern singleton invece di usare una classe con soli membri statici? operativamente mi sembra la stessa cosa... o mi sfugge qualcosa?

No, sono cose diverse. In Java, ad esempio, una classe come java.lang.Math ha il costruttore private e tutti i membri sono static e compiono solo operazioni matematiche. Non viene creata alcuna istanza di Math né all'interno di Math né, ovviamente, all'esterno.

Il pattern singleton prevede che ci sia un metodo statico che ritorna una istanza (l'unica possibile) della classe.

[mad_hhatter]

Originariamente inviato da andbin

No, sono cose diverse. In Java, ad esempio, una classe come java.lang.Math ha il costruttore private e tutti i membri sono static e compiono solo operazioni matematiche. Non viene creata alcuna istanza di Math né all'interno di Math ne, ovviamente, all'esterno.

Il pattern singleton prevede che ci sia un metodo statico che ritorna una istanza (l'unica) della classe.

si lo so bene... la mia domanda, evidentemente espressa male, è:

perchè usare il pattern singleton per fare quello che, se non sto prendendo cantonate, si può fare con una classe con soli membri statici?

[cionci]

Io il problema non me lo pongo, visto che non mi piacciono sia le classi con soli membri statici che il singleton pattern (tra l'altro l'uso, ma soprattutto l'abuso, è sconsigliato anche da chi l'ha messo su carta).
Comunque prima di tutto ci sono differenze a livello operativo: la classe con i soli metodi statici non ha un costruttore. Si può ovviare a questo mettendo un membro statico di controllo che richiami un membro statico "costruttore", ma crea notevoli ripetizioni nel codice, un codice con troppe ripetizioni non è un buon codice.
Altri dubbi mi vengono dal significato che assume una classe con tutti membri statici...se le critiche mosse al singleton sono quelle di andare a ricreare una sorta di variabile globale quando anche nella programmazione non OO cercavamo di farne il più possibile a meno, le critiche che si possono fare alla classe di metodi statici sono ancora più serie: è la negazione della programmazione OO, in quanto di fatto si buttano dalla finestra le funzioni globali per reintrodurle da sotto la porta

[mad_hhatter]

Originariamente inviato da cionci

Io il problema non me lo pongo, visto che non mi piacciono sia le classi con soli membri statici che il singleton pattern (tra l'altro l'uso, ma soprattutto l'abuso, è sconsigliato anche da chi l'ha messo su carta).
Comunque prima di tutto ci sono differenze a livello operativo: la classe con i soli metodi statici non ha un costruttore. Si può ovviare a questo mettendo un membro statico di controllo che richiami un membro statico "costruttore", ma crea notevoli ripetizioni nel codice, un codice con troppe ripetizioni non è un buon codice.
Altri dubbi mi vengono dal significato che assume una classe con tutti membri statici...se le critiche mosse al singleton sono quelle di andare a ricreare una sorta di variabile globale quando anche nella programmazione non OO cercavamo di farne il più possibile a meno, le critiche che si possono fare alla classe di metodi statici sono ancora più serie: è la negazione della programmazione OO, in quanto di fatto si buttano dalla finestra le funzioni globali per reintrodurle da sotto la porta

perfettamente d'accordo. ma nei rari casi in cui è necessaria un'entità centralizzata che deve essere accessibile a più entità clienti senza la necessità di passare l'oggetto condiviso come parametro che altre strade hai? una factory ha molti vantaggi a livello di design ed è un singleton, per esempio...

io ritengo che l'abuso di qualsiasi cosa sia dannoso (salvo eccezioni che sarebbero OT ), ma l'uso oculato è, per definizione, buona cosa.

Quanto al costruttore: creare un singleton con un parametro di costruzione è una cosa delicata di per sè... comuqnue questa situazione mi pare l'unica in cui un singleton è diverso da una classe con solo membri statici... è corretto?

grazie a tutti per i vostri interventi passati e futuri

[cionci]

Originariamente inviato da mad_hhatter

perfettamente d'accordo. ma nei rari casi in cui è necessaria un'entità centralizzata che deve essere accessibile a più entità clienti senza la necessità di passare l'oggetto condiviso come parametro che altre strade hai? una factory ha molti vantaggi a livello di design ed è un singleton, per esempio...

Non è detto che debba essere un singleton, se la si astrae debitamente di comporterà come un singleton, ma non lo sarà. Soprattutto non la si rende disponibile ovunque come una variabile globale.

Originariamente inviato da mad_hhatter

Quanto al costruttore: creare un singleton con un parametro di costruzione è una cosa delicata di per sè... comuqnue questa situazione mi pare l'unica in cui un singleton è diverso da una classe con solo membri statici... è corretto?

Non è tanto il parametro del costruttore il problema, ma se l'oggetto istanziato una sola volta ha necessità di operazioni di inzializzazione.

[mad_hhatter]

Originariamente inviato da cionci

Non è tanto il parametro del costruttore il problema, ma se l'oggetto istanziato una sola volta ha necessità di operazioni di inzializzazione.

un inizializzatore statico non va bene?

[cionci]

Originariamente inviato da mad_hhatter

un inizializzatore statico non va bene?

Certo che va bene, ma in ogni altro metodo statico devi controllare se l'inizializzazione è già avvenuta e se non è avvenuta devi chiamare il metodo statico che fa l'inizializzazione.

if(!initDone) doInit();

Il che implica una duplicazione in ogni metodo statico.

[mad_hhatter]

Originariamente inviato da cionci

Certo che va bene, ma in ogni altro metodo statico devi controllare se l'inizializzazione è già avvenuta e se non è avvenuta devi chiamare il metodo statico che fa l'inizializzazione.

if(!initDone) doInit();

Il che implica una duplicazione in ogni metodo statico.

scusa, ma in java c'è il blocco static{} richiamato quando la classe viene caricata, in c# ci sono i costruttori statici... non fanno proprio quello di cui parli?

[cionci]

Originariamente inviato da mad_hhatter

scusa, ma in java c'è il blocco static{} richiamato quando la classe viene caricata, in c# ci sono i costruttori statici... non fanno proprio quello di cui parli?

In C++ non c'è niente di tutto questo...facevo riferimento a quello

[Ufo13]

Odio il singleton pattern, abusato da molti perche` altrimenti non sanno come passare variabili nei metodi.

Si tratta dell'equivalente di scrivere codice C usando variabili globali invece che parametri e questa e` una cosa comunemente riconosciuta come sbagliata.

Il singleton e` piu` accettato, secondo me, perche`:
- E` un pattern quindi usarlo e` bene anche se leggendo i lpattern si son saltate un po` di righe...
- E` object oriented.
- E` sempre meglio che usare variabili globali.

Comunque non so se ti riferisci a Java o C# ma in C++ il singleton viene usato principalmente perche` l'ordine di inizializzazione delle variabili globali e` undefined e se hai singleton che usano altri singleton nel costruttore (oddio!!!) avresti comportamento undefined.

Ultima nota sul singleton pattern: si usa il singleton pattern quando il design esplicitamente richiede che esista UNA SOLA istanza di quell'oggetto e se mai nella vita del progetto dovessero esistere due o piu` istanze questo sarebbe un grave errore.

[mad_hhatter]

Originariamente inviato da Ufo13

Odio il singleton pattern, abusato da molti perche` altrimenti non sanno come passare variabili nei metodi.

Si tratta dell'equivalente di scrivere codice C usando variabili globali invece che parametri e questa e` una cosa comunemente riconosciuta come sbagliata.

Il singleton e` piu` accettato, secondo me, perche`:
- E` un pattern quindi usarlo e` bene anche se leggendo i lpattern si son saltate un po` di righe...
- E` object oriented.
- E` sempre meglio che usare variabili globali.

il fatto che molti usino male alcuni strumenti non fa di questi strumenti una cosa negativa... il fatto che molti scrivano cattivo codice in un linguaggio X non rende il linguaggio X una schifezza.

Una variabile globale è assolutamente non protetta, un oggetto o una classe permettono l'incapsulamento, non è assolutamente la stessa cosa!

"Generalmente" non significa "sempre"

quanto alla tua lista di punti:
- non uso cose perchè altri mi han detto che è bene: voglio sapere SE, QUANDO e PERCHE' è bene (e quali sono i compromessi)... per questo ho aperto il thread chiedendo la differenza tra una classe con membri static e un singleton
- va beh, ma oop è un paradigma, non il dio supremo
- ho già scritto a riguardo poche righe fa

Originariamente inviato da Ufo13

Ultima nota sul singleton pattern: si usa il singleton pattern quando il design esplicitamente richiede che esista UNA SOLA istanza di quell'oggetto e se mai nella vita del progetto dovessero esistere due o piu` istanze questo sarebbe un grave errore.

se non fosse così non starei prendendo in considerazione il singleton pattern

[PGI-Bis]

Una classe con metodi statici genera una dipendenza di definizione che, per l'orientamento agli oggetti, significa che oggetto è l'unione tra la definizione di quella classe e quella della classe utente.

E' corretto quando dici "l'unica differenza mi pare essere quella del costruttore con argomenti" perchè il confronto che fai è tra due forme Java che, sempre dal punto di vista dell'orientamento agli oggetti, generano entrambe dipendenza di definizione. Resta solo il "dettaglio tecnico" del costruttore.

Al bocciofilo si dice che questo sia sbagliato. In verità è una questione di significati. L'orientamento agli oggetti è una prospettiva totalizzante. Non ci sono cose incompatibili con l'orientamento agli oggetti ma semplici alterazioni di significato. Dell'unico significato esistente nell'orientamento agli oggetti, vale a dire cosa sia oggetto e cosa sia parte della definizione di un oggetto.

[mad_hhatter]

Originariamente inviato da PGI-Bis

Una classe con metodi statici genera una dipendenza di definizione che, per l'orientamento agli oggetti, significa che oggetto è l'unione tra la definizione di quella classe e quella della classe utente.

E' corretto quando dici "l'unica differenza mi pare essere quella del costruttore con argomenti" perchè il confronto che fai è tra due forme Java che, sempre dal punto di vista dell'orientamento agli oggetti, generano entrambe dipendenza di definizione. Resta solo il "dettaglio tecnico" del costruttore.

Al bocciofilo si dice che questo sia sbagliato. In verità è una questione di significati. L'orientamento agli oggetti è una prospettiva totalizzante. Non ci sono cose incompatibili con l'orientamento agli oggetti ma semplici alterazioni di significato. Dell'unico significato esistente nell'orientamento agli oggetti, vale a dire cosa sia oggetto e cosa sia parte della definizione di un oggetto.

ehm... ti offendi (e io faccio tanto la figura del babbeo) se ti confesso che credo di non aver capito bene?

soprattutto quando parli di dipendenza di definizione

[Ufo13]

Originariamente inviato da mad_hhatter

il fatto che molti usino male alcuni strumenti non fa di questi strumenti una cosa negativa... il fatto che molti scrivano cattivo codice in un linguaggio X non rende il linguaggio X una schifezza.

L'uso corretto del singleton e` quello di forzare una sola istanza.

Ricordo in diamonds i test che fallivano senza motivo per colpa del singleton pattern e l'uso oltrettutto era corretto...

[Nous]

Originariamente inviato da mad_hhatter

perchè usare il pattern singleton per fare quello che, se non sto prendendo cantonate, si può fare con una classe con soli membri statici?

Una classe con i soli metodi statici è una classe di utilità, che fornisce metodi il cui output dipende solo dall'input fornito e non dallo stato dell'oggetto (che non hai perchè non istanzi la classe). Esempio : un metodo che somma due numeri.

Il pattern singleton lo usi quando vuoi che ci sia una sola istanza di una classe per tutta la durata dell'applicazione, mediamente quando vuoi che ad una risorsa acceda sempre una classe per evitare problemi di concorrenza o di (mancanza di) atomicità sui dati. Esempio : un logger di sistema, ne vuoi uno solo che si occupi di memorizzare gli eventi sul sistema. Hai un'istanza, quindi hai un'oggetto con uno stato e i metodi che fornisce la classe modificano lo stato dell'oggetto (almeno in teoria, in pratica dipende dal tuo modo di vedere la programmazione ad oggetti).

[Nous]

Originariamente inviato da cionci

la classe con i soli metodi statici non ha un costruttore.

Falso, il costrutto di default è sempre implicito. Tant'è che una buona classe di utilità dovrebbe definire esplicitamente il costruttore e con scope privato.

[cionci]

Originariamente inviato da Nous

Falso, il costrutto di default è sempre implicito. Tant'è che una buona classe di utilità dovrebbe definire esplicitamente il costruttore e con scope privato.

Il costruttore di default c'è ma non viene mai utilizzato
Se io uso la classe con i soli metodi statici il costruttore di default non verrà mai chiamato.
Allora mettiamola così: una classe con soli metodi statici non ha un costrutto equivalente al costruttore che permette di inizializzare la classe, almeno in C++ a quanto sembra.

[Nous]

Originariamente inviato da cionci

Il costruttore di default c'è ma non viene mai utilizzato
Se io uso la classe con i soli metodi statici il costruttore di default non verrà mai chiamato.
Allora mettiamola così: una classe con soli metodi statici non ha un costrutto equivalente al costruttore che permette di inizializzare la classe, almeno in C++ a quanto sembra.

Sì ma è istanziabile, provare per credere
E' sbagliato che lo sia...e quindi si deve renderlo non istanziabile

[cionci]

Originariamente inviato da Nous

Sì ma è istanziabile, provare per credere
E' sbagliato che lo sia...e quindi si deve renderlo non istanziabile

Certo che lo è...vorrei anche vedere...