Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > it.comp.www.php > #20604 > unrolled thread

decoratori non di classe

Back to article view | Back to it.comp.www.php

Contents

  decoratori non di classe alex <1j9448a02@lnx159sneakemail.com.invalid> - 2016-04-06 18:29 +0200
    Re: decoratori non di classe Alessandro Pellizzari <shuriken@amiran.it> - 2016-04-06 17:54 +0100
      Re: decoratori non di classe alex <1j9448a02@lnx159sneakemail.com.invalid> - 2016-04-06 19:14 +0200
        Re: decoratori non di classe fmassei@gmail.com - 2016-04-06 10:42 -0700
          Re: decoratori non di classe alex <1j9448a02@lnx159sneakemail.com.invalid> - 2016-04-06 21:12 +0200
            Re: decoratori non di classe fmassei@gmail.com - 2016-04-06 13:00 -0700

#20604 — 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?

[toc] | [next] | [standalone]

#20605

On 06/04/2016 17:29, alex wrote:

> Class PositiveNumber {// è un Decorator?
>      function __construct($number) {
 > ...
> 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?

No.

Un decoratore deve implementare la stessa interface dell'oggetto wrappato.

In PHP i tipi base non sono oggetti, quindi non puoi decorarli.

Bye.

[toc] | [prev] | [next] | [standalone]

#20606

Il 06/04/2016 18:54, Alessandro Pellizzari ha scritto:
> 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?

[toc] | [prev] | [next] | [standalone]

#20607

On Wednesday, April 6, 2016 at 1:14:50 PM UTC-4, alex wrote:
> Il 06/04/2016 18:54, Alessandro Pellizzari ha scritto:
> > No.
> >
> > Un decoratore deve implementare la stessa interface dell'oggetto wrappato.
> >
> > In PHP i tipi base non sono oggetti, quindi non puoi decorarli.
> >
> 
> 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!

[toc] | [prev] | [next] | [standalone]

#20608

Il 06/04/2016 19:42, fmassei@gmail.com ha scritto:
> 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é..
>

L'obiettivo è proprio questo.

> 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.

Ma certo...

> 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".

E non è raro in questi casi riutilizzare un trait a cui (al momento 
dello sviluppo) bisogna dare un nome: DecoratorTrait, GenericWrapperTrait?
E per dare un nome (il più appropriato possibile) bisogna conoscere bene 
i concetti di wrapper, decorator, adapter...
Forse stai intuendo il motivo delle mie domande... questione di 
organizzazione concettuale, professionalità...

> 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!:)
>

Eddai ho capito, per chi mi prendi?
:)

> 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.

E' quello che faccio da anni (la pratica), ma ad un certo punto serve 
anche un po' di teoria riorganizzativa.

[toc] | [prev] | [next] | [standalone]

#20609

On Wednesday, April 6, 2016 at 3:12:11 PM UTC-4, alex wrote:
> Il 06/04/2016 19:42, fmassei@gmail.com ha scritto:
> > 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!:)
> >
> 
> Eddai ho capito, per chi mi prendi?
> :)
> 

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!

[toc] | [prev] | [standalone]

Back to top | Article view | it.comp.www.php

csiph-web