[Singleton] Ultima puntata

A proposito di questi cavolo di Singleton in JS seguendo le direttive dei
pattern GoF, sono arrivato ad una conclusione, *non è possibile farlo alla
lettera in JS*!
Tuttavia con piccolissimi riadattamenti al linguaggio sono riuscito a
partorire questo:

var SingletonClass;
(function()
{
var instance;
SingletonClass = function( )
{
if( this == window )
{
alert( 'Attenzione non è una funzione!' );
return;
}
// else if( this.prototype != SingletonClass.prototype )
else if( ! ( this instanceof SingletonClass ) )
{
alert( 'Che cavolo stai dicendo Willis!' );
return;
}
else if( instance )
return instance;
else
instance = this;

this.$ = 'ciao';
this.f = function()
{
alert( this.$ );
}
}
SingletonClass.getInstance = function( )
{
return instance || ( instance = new SingletonClass( ) );
}
})();

E a meno che non abbia detto l'ennesima castroneria, le seguenti 3
istruzioni daranno sempre la medesima istanza:

var a = new SingletonClass();
var b = new SingletonClass();
var c = SingletonClass.getInstance( );

e già che c'ero ho stabilito che non si potesse usare in altri contesti...
come ad esempio:

SingletonClass();
document.forms[0].myButton.onclick = SingletonClass;


Vai Zer0 dimmi di tutto :P

Ugo <privacy (AT) nospam (DOT) it> wrote:

A proposito di questi cavolo di Singleton in JS seguendo le direttive dei
pattern GoF, sono arrivato ad una conclusione, *non è possibile farlo alla
lettera in JS*!

E' possibilissimo, a meno che tu non confonda i pattern con la loro
implementazione.
Un pattern è una metodologia, un approccio, una via da seguire. Non
un'implementazione pratica.

Tuttavia con piccolissimi riadattamenti al linguaggio sono riuscito a
partorire questo:

Mi sa che a te le closure ti hanno un po' rovinato.

E a meno che non abbia detto l'ennesima castroneria,

Non ho controllato il codice, ma non condivido l'approccio. Però, è
una cosa personale: se si adatta alle tue specifiche esigenze, e ti
risulta comoda, ben venga.

Vai Zer0 dimmi di tutto :P

Quel che ti dovevo dire circa il Sigleton te l'ho già detto diverse
volte. Per quanto riguarda lo specifico codice, come ho detto, temo
che le closure ti abbiano un po' rovinato. Mi sa che sei caduto nel
Golden Hammer, che è un anti pattern. E l'approccio non mi convince
perché a mio avviso sei andato a snaturare un po' troppo JS.
Non hai creato una funzione costruttrice "SingletonClass" bensì una
funzione anonima da associare a una variabile "SingletonClass"; non
hai sfruttato il prototype a dovere e hai creato diverse closure, e
senza reale necessità (mi riferisco ad esempio al this.f). Inoltre,
è poco generalizzato (il getInstance, ad esempio).

Hope it helps.

--
"Se c'è qualcosa di più importante del mio ego su questa nave,
la voglio catturata e fucilata."

A proposito di questi cavolo di Singleton in JS seguendo le direttive dei
pattern GoF, sono arrivato ad una conclusione, *non è possibile farlo alla
lettera in JS*!

E' possibilissimo, a meno che tu non confonda i pattern con la loro
implementazione.

Sì esatto

Un pattern è una metodologia, un approccio, una via da seguire. Non
un'implementazione pratica.

ok, giusto

Tuttavia con piccolissimi riadattamenti al linguaggio sono riuscito a
partorire questo:

Mi sa che a te le closure ti hanno un po' rovinato.

Mi piacciono tantissimo

E a meno che non abbia detto l'ennesima castroneria,

Non ho controllato il codice, ma non condivido l'approccio.

Ettepareva

Però, è una cosa personale:

Beh, abbiamo fatto dei progressi, questa volta non mi hai completamente
smontato - forse hai avuto pietà ed hai apprezzato l'impegno

se si adatta alle tue specifiche esigenze, e ti
risulta comoda, ben venga.

a dire il vero a me sembrerebbe più comodo avere un oggetto literal globale
e riferirmi direttamente a quello senza chiamare una metodo..., però per
certi aspetti assomiglia ad una variabile globale e quindi mi ero
"intrippato" in questa cosa di creare un singleton seguendo
l'implementazione tradizionale del pattern definito da GoF (di cui non sono
ancora riuscito a leggere il libro) e cioè creare un metodo statico che
desse la restituzione dell'unica istanza e che impedisse un'instanziazione
diretta, e con questa implementazione mi sembra di essermi avvicinato
parecchio.
Per quanto riguarda l'uso della chiusura per l'istanza, mi è sembrato
l'unico modo per farla accedere dal costruttore e dal metodo statico
evitanto altri tipi di accessi (altrimenti avrei potuto fare una proprietà
statica pubblica)

Vai Zer0 dimmi di tutto :P

Quel che ti dovevo dire circa il Sigleton te l'ho già detto diverse
volte. Per quanto riguarda lo specifico codice, come ho detto, temo
che le closure ti abbiano un po' rovinato. Mi sa che sei caduto nel
Golden Hammer, che è un anti pattern.

E l'approccio non mi convince
perché a mio avviso sei andato a snaturare un po' troppo JS.
Non hai creato una funzione costruttrice "SingletonClass" bensì una
funzione anonima da associare a una variabile "SingletonClass";

e già mi è servito per creare la chiusura instance

non
hai sfruttato il prototype a dovere e hai creato diverse closure, e
senza reale necessità (mi riferisco ad esempio al this.f).

vabbe' quello era esemplificativo mi era più comodo e sintetico scrivere
così che:
SingletonClass.prototype.f = function()
{
alert( this.$ );
}
la classe si potrebbe fare un po' come si ritiene se ho bisogno di fare
delle chiusure o altrimenti prototipizzando...

Inoltre,
è poco generalizzato (il getInstance, ad esempio).

nel senso che non riuscirei..., mmm, no non ho capito

Hope it helps.

la colpa della fissa che mi è venuta di fare un "bel" singleton
l'attribuisco a te, tu sei la causa di tutto e hai creato un mostro che
inizia ad adottare una programmazione un po' più OOP e quindi ora sono
cavoli tuoi
e sentiti anche in dovere

On Sun, 25 May 2008 23:53:36 +0200, Ugo wrote:

Un pattern è una metodologia, un approccio, una via da seguire. Non
un'implementazione pratica.

ok, giusto

Ecco. Ricordatelo sempre, a prescindere dal Singleton.

Mi sa che a te le closure ti hanno un po' rovinato.

Mi piacciono tantissimo

Vedi di fartele piacere meno. Lo dico per te. Mi sembra di non
essere stato neanche l'unico a "cazziarti" su questa cosa (ma non
ho seguito interamente il thread su clj).

se si adatta alle tue specifiche esigenze, e ti
risulta comoda, ben venga.

a dire il vero a me sembrerebbe più comodo avere un oggetto literal globale
e riferirmi direttamente a quello senza chiamare una metodo...

E allora usa quello, no?

però per
certi aspetti assomiglia ad una variabile globale

Da questo punto di vista in JS su browser "tutto assomiglia a una
variabile globale". Del resto un oggetto siffatto è una proprietà
di window, parimenti a una funzione "Singleton".

e quindi mi ero
"intrippato" in questa cosa di creare un singleton seguendo
l'implementazione tradizionale del pattern definito da GoF

Non esiste un "implementazione tradizionale". I GoF forniscono un
paio di esempi per i pattern i C++ e Smalltalk, ma sono *esempi*.
Non sono "implementazioni consigliate" o altro. Loro, definiscono
unicamente che cos'è il pattern. Ne descrivono il comportamento e
poco altro.
Poi ti dicono "Ok, per farti capire meglio in C++ e Smalltalk si
può implementare così".

(di cui non sono ancora riuscito a leggere il libro)

Male.

e cioè creare un metodo statico che
desse la restituzione dell'unica istanza e che impedisse un'instanziazione
diretta, e con questa implementazione mi sembra di essermi avvicinato
parecchio.

Peccato per lo sviluppo del codice.

Per quanto riguarda l'uso della chiusura per l'istanza, mi è sembrato
l'unico modo per farla accedere dal costruttore e dal metodo statico
evitanto altri tipi di accessi (altrimenti avrei potuto fare una proprietà
statica pubblica)

Anche, e ti saresti evitato una closure. Ma anche utilizzando una
closure per tale scopo, puoi indubbiamente fare meglio di così.
Ora è veramente buttata a casaccio: si vede che hai letto qualche
articolo sulle closure e sull'emulazione di "membri privati", non
comprendendolo appieno (mi viene da pensare a Crockford), difatti
stai usando quelle cognizioni a sproposito. Indubbiamente è anche
perché ti sei fatto prendere dalla sindrome del "Golden Hammer".

Quel che ti dovevo dire circa il Sigleton te l'ho già detto diverse
volte. Per quanto riguarda lo specifico codice, come ho detto, temo
che le closure ti abbiano un po' rovinato. Mi sa che sei caduto nel
Golden Hammer, che è un anti pattern.

Studiati anche quello.
E' utile conoscere gli anti-pattern quanto i pattern. Soprattutto
quando ci si rende conto di essere succubi di uno di questi.

E l'approccio non mi convince
perché a mio avviso sei andato a snaturare un po' troppo JS.
Non hai creato una funzione costruttrice "SingletonClass" bensì una
funzione anonima da associare a una variabile "SingletonClass";

e già mi è servito per creare la chiusura instance

Assolutamente no, puoi farne benissimo a meno. E' per questo, che
ti dico che probabilmente non ti sono ben chiare le meccaniche di
quello che hai letto. Puoi mantenere la closure senza scrivere un
codice così schifido.

non
hai sfruttato il prototype a dovere e hai creato diverse closure, e
senza reale necessità (mi riferisco ad esempio al this.f).

vabbe' quello era esemplificativo mi era più comodo e sintetico scrivere
così che:
SingletonClass.prototype.f = function()
{
alert( this.$ );
}

Si, peccato che si tratti di due cose completamente diverse.
Può essere una questione sintetica, quando due cose più o meno si
equivalgono, allora la scelta di una piuttosto che dell'altra non
è rilevante.

Inoltre,
è poco generalizzato (il getInstance, ad esempio).

nel senso che non riuscirei..., mmm, no non ho capito

Non c'è molto da capire: questo approccio non è generalizzato.
Soprattutto, ripeto, il getInstance().

Hope it helps.

la colpa della fissa che mi è venuta di fare un "bel" singleton
l'attribuisco a te,

Non ti ci provare neanche, sei tu che ti ci sei incaponito.

Tra l'altro non devi mai dimenticarti la natura del linguaggio su
cui stai sviluppando, ricordatelo. Dovresti seguire la sua natura
quando scrivi del codice.

tu sei la causa di tutto e hai creato un mostro che
inizia ad adottare una programmazione un po' più OOP

Io posso assumermi la responsabilità di averti "spinto" verso un
approccio più OOP; ma se sei diventato un "mostro" questa è solo
colpa tua. ;P

--
~ "Finestre, finestre, finestre! Sennò prevalgono i muri."
(Marco Paolini)