Newsgroup: it.comp.www.php
Titolo: decoratori non di classe

class Wrapped {
	function test() {
		// fai qualcosa
	}
}
 
Class Decorator {
	function __construct(Wrapped $wrapped) {
		$this->wrapped = $wrapped;
	}
 
	function test() {
		// fai qualcosa
		$this->wrapped->test();
	}
}
 
Bene!!!
Adesso però osservate la seguente classe
 
Class PositiveNumber {// è un Decorator?
	function __construct($number) {
		if ($number <= 0) {
			throw new Exception('numero non positivo');
		}
		$this->wrapped = $number;
	}
 
	function get() {
		return $this->wrapped;
	}
}
 
Come vedete però in questo caso il *wrapped* non deve essere un'istanza 
della classe Wrapped, ma bensì un numero (positivo).
Da qui sorge la domanda: la classe PositiveNumber può essere considerata 
un decoratore?

 un decoratore?
 
No.
 
Un decoratore deve implementare la stessa interface dell'oggetto wrappato.
 
In PHP i tipi base non sono oggetti, quindi non puoi decorarli.
 
Bye.
 


 
ma almeno possiamo considerarlo un wrapper?


 
Il fatto che provi cose e sperimenti pattern è lodevole, sicuramente è un modo
per fissare in testa i concetti che uno studia, ma secondo me stai un po'
andando fuori strada, ti dico perché..
 
Questi pattern non derivano da leggi, teoremi o chissà cos'altro, sono solo
un insieme di idee che, nel corso degli anni, hanno formato una collezione
di strumenti a disposizione di chi fa software engineering. I nomi alle cose
si danno perché beh, altrimenti sarebbe un casino per capirsi :) però non
sono importanti. L'importante è l'idea che è dietro ciascuno, e questa idea
è strettamente legata ad un particolare problema che si cerca di risolvere.
Normalmente non è che dici "vabbè, ora scrivo un decorator", normalmente hai
un problema specifico e dici "questo mi ricorda proprio quel caso in cui un
decorator mi semplifica il lavoro".
Lo scrivo perché è particolarmente importante capire che, nella vita reale,
non avrai mai la struttura pulita pari pari a quella che trovi sui libri:
bisogna prendere tutte le idee e mischiarle insieme per ottenere la struttura
unica cucita sul tuo progetto.
E' come negli scacchi: puoi imparare a memoria tutti i nomi di tutte le
aperture, ma se non sai le posizioni a cui portano e come imbastire un piano
di gioco a partire da queste perderai quasi sempre! :)
 
Secondo me dovresti continuare sì come stai facendo, ma a partire da un
problema (più o meno) reale: è questo che addestra la mente ad usare non i
pattern in se, ma le idee dietro ad ognuno.
 
M2C,
Ciao!

 pattern in se, ma le idee dietro ad ognuno.
 
E' quello che faccio da anni (la pratica), ma ad un certo punto serve 
anche un po' di teoria riorganizzativa.
 
 

 
 
Beh, io ho all'inizio ho fatto proprio quest'errore, sia in informatica che
negli scacchi :)
In effetti di sicuro non sono una volpe :D
 
Nell'OOP lo fanno in moltissimi: non è raro vedere programmatori "giovani",
specialmente javisti, che tirano su classi del tipo "classe base per gli
adapters" o cercano di crearne una da cui derivare singletons.
Anche te prima chiedevi che nome dare ad una trait: "DecoratorTrait"? Sono
tutti approcci e domande concettualmente errati..
Un pattern non è un concetto, e quindi non va tradotto con una classe! E' una
struttura che una o più classi possono avere per interagire tra loro..
 
Esempio (che credo Alessandro abbia fatto qualche tempo fa), gestire una
configurazione sia YAML che su DB:
le cassi quelle sono, ConfigurazioneYAML e ConfigurazioneDB. Poi sta a te
decidere come interagiscono tra loro e con il resto del codice. Probabilmente
hanno funzioni in comune, allora puoi fare una classe base e derivare, oppure
fare dei decorators, è uguale. Magari la ConfigurazioneDB è anche un
singleton, e magari la devi pure creare con un factory. Forse altre classi di
terze parti usano pezzi specifici di configurazione che vogliono un altro
formato, e ti serve uno o più adapters, magari uniti ad un flyweight.
Ecco che stai usando cinque sei pattern insieme, ma le classi sempre due sono!
:)
 
Vedila da un altro punto di vista: perché non esistono linguaggi che ti danno
la possibilità di creare, con delle keywords (tipo class, abstract, public,
etc.) anche degli specifici pattern (tipo factory, decorator, etc.)?
Domandona, eh? :)
La risposta è facile, perché sarebbe inutile! :)
 
Specifico perché i design patterns sono stati creati per semplificare la
struttura, ma visto che quando uno inizia a vederli sembrano complessi, molti
pensano che si tratti di roba da imparare a memoria e applicare ad occhi
chiusi: se ad un certo punto ti trovi in difficoltà a rientrare in un pattern
che hai scelto, o se devi scrivere tanto più codice, o aggiungere troppe
classettine intermedie, allora sta succedendo qualcosa di profondamente
sbagliato. E sfortunatamente succede molto spesso..
 
Ciao!