I fornitori di una factory

[Jacopo Romei]

Ciao a tutti!

1. Una factory si occupa di prepararmi un oggetto a seconda delle condizioni di contesto.

2. Un factory quindi se ne assume la responsabilità e in base al principio "tell don't ask" non deve mostrare troppe sue pudenda, quindi non deve, in virtù del principio suddetto, ricevere le dipendenze necessarie ai suoi prodotti finiti.

3. Un sano principio di testabilità, però, ci porta a voler garantire la 'sostituibilità' degli stessi componenti necessari alla costruzione dei prodotti della factory.

4. La factory, inoltre, è uno di quei pattern che servono a incapsulare una zona di contatto del nostro sistema con il mondo 'sporco e infetto là fuori' e - per esempio - necessariamente dovrà aggregare, montare, istanziare esplicitamente, dipendere in modo 'hardcoded' da altre classi.

La domanda è, tutto considerato: posso sacrificare parte della testabilità della factory come *unità* disaccoppiata dal resto in favore di un test più d''integrazione' che però mi permetta di sviluppare factory più coese?

www.domandecriptiche.it/dubbioso78

--
Jacopo Romei
http://www.sviluppoagile.it/
http://twitter.com/jacoporomei
http://www.anonimarmonisti.com/

[leonardo proietti]

>posso sacrificare parte della testabilità della factory come *unità* disaccoppiata dal resto

>in favore di un test più d''integrazione' che però mi permetta di sviluppare factory più coese?

me la rischio: secondo me si :-)

riferendomi a Sf2, una cosa simile succede usando il DIC come service locator

e infatti testare unitariamente un controller (non esposto come servizio) è praticamente inutile;

tra l'altro nel caso del controller non c'è nemmeno l'esigenza di coesione.

Ciao
Leonardo

[Alessandro Nadalin]

Risposta veloce: si, sbattitene.

Risposta elucubrata:

Factory e', a mio modesto parere, un pattern abbastanza di prima generazione (assieme a singleton e registry) che, pur essendo comodi, influiscono abbastanza negativamente sulla pulizia del codice. Pero' anche esticazzi: se usati con parsimonia e nel contesto giusto sono comunque delle armi utili ad alcuni fini.

La factory nel tuo caso fa parte di uno strato dell'applicazione che *molto* probabilmente non dovra' essere sottoposto a test unitari per garantirne il funzionamento - un po' come dice Leo per i controller: testare unitariamente un controller (sempre imho) e' utile come un rifugio antiatomico nell'antartico, ovvero si' non ne puoi negare l'utilita' spicciola, ma e' veramente spicciola.

Rientrando nel dominio di utility&configuration, mi premerebbe invece che la factory venisse testata indirettamente attraverso test funzionali o di comportamento.

My 2 cents

2013/4/12 Jacopo Romei <jro...@gmail.com>

--
Hai ricevuto questo messaggio perché sei iscritto al gruppo "PUG Roma" di Google Gruppi.
Visita questo gruppo all'indirizzo http://groups.google.com/group/pug-roma?hl=it-IT.
 
 

--
Nadalin Alessandro
www.odino.org
www.twitter.com/_odino_

[Eugenio Pombi]

sono d'accordo con leo e ale.

Aggiungo solo che a volte mi è capitato di usare il DIC per iniettare nella factory alcune dipendenze che fanno parte di una o più delle istanze che vengono ritornate dalla factory stessa.

Mi spiego meglio: mi fa paura quando nella factory uno non deve istanziare solo l'oggetto che vuole ottenere ma anche le sue dipendenze, la factory comincia a quel punto a "sapere troppe cose".

In quel caso delego al DIC la creazione delle dipendenze necessarie agli oggetti che la factory restituisce.

Eugenio Pombi
Developer

tel:      +39.329.5455797
mail:    eux...@gmail.com
twitter: @euxpom
skype: euxeux

it.linkedin.com/pub/eugenio-pombi/3b/28b/99a

[alessandro cinelli]

2013/4/14 Eugenio Pombi <eux...@gmail.com>

sono d'accordo con leo e ale.

Aggiungo solo che a volte mi è capitato di usare il DIC per iniettare nella factory alcune dipendenze che fanno parte di una o più delle istanze che vengono ritornate dalla factory stessa.

Mi spiego meglio: mi fa paura quando nella factory uno non deve istanziare solo l'oggetto che vuole ottenere ma anche le sue dipendenze, la factory comincia a quel punto a "sapere troppe cose".

Quello che descrivi tu è un Builder: http://en.wikipedia.org/wiki/Builder_pattern

Comunque non sono totalmente d'accordo con Ale, o meglio: non sono convinto.

Se ho una factory non banale, andrebbe anch'essa testata.

Un controller funge da collante tra i vari oggetti e si può anche saltare la fase ti test, ma il ruolo della factory, o di un qualsiasi "creational" pattern secondo me è più complesso e non va scartata a priori lo sviluppo di test.

"Factory e', a mio modesto parere, un pattern abbastanza di prima generazione (assieme a singleton e registry) che, pur essendo comodi, influiscono abbastanza negativamente sulla pulizia del codice."

Quali altre soluzioni adotteresti?

cirpo

--
@cirpo

[Alessandro Nadalin]

2013/4/14 alessandro cinelli <alessandr...@gmail.com>

2013/4/14 Eugenio Pombi <eux...@gmail.com>

sono d'accordo con leo e ale.

Aggiungo solo che a volte mi è capitato di usare il DIC per iniettare nella factory alcune dipendenze che fanno parte di una o più delle istanze che vengono ritornate dalla factory stessa.

Mi spiego meglio: mi fa paura quando nella factory uno non deve istanziare solo l'oggetto che vuole ottenere ma anche le sue dipendenze, la factory comincia a quel punto a "sapere troppe cose".

Quello che descrivi tu è un Builder: http://en.wikipedia.org/wiki/Builder_pattern

Comunque non sono totalmente d'accordo con Ale, o meglio: non sono convinto.

Se ho una factory non banale, andrebbe anch'essa testata.

Un controller funge da collante tra i vari oggetti e si può anche saltare la fase ti test, ma il ruolo della factory, o di un qualsiasi "creational" pattern secondo me è più complesso e non va scartata a priori lo sviluppo di test.

se la factory costruisce oggetti aggregati forse, altrimenti il suo scope rimane quello di utility senza fine a se' stessa, per la quale usi i test d'integrazione

 

"Factory e', a mio modesto parere, un pattern abbastanza di prima generazione (assieme a singleton e registry) che, pur essendo comodi, influiscono abbastanza negativamente sulla pulizia del codice."

Quali altre soluzioni adotteresti?

Factory: DI

Singleton: DI

Registry: DI

:)

[alessandro cinelli]

 Non comprendo. La  DI la ottieni dopo aver usato una factory per creare i tuoi oggetti.

DI != factory

Come crei degli oggetti dinamicamente senza un builder/factory/proxy?

Cirpo

 

Singleton: DI

Registry: DI

 

 

:)

 

--
Nadalin Alessandro
www.odino.org
www.twitter.com/_odino_

--

Hai ricevuto questo messaggio perché sei iscritto al gruppo "PUG Roma" di Google Gruppi.
Visita questo gruppo all'indirizzo http://groups.google.com/group/pug-roma?hl=it-IT.
 
 

--
@cirpo

[leonardo proietti]

>Un controller funge da collante tra i vari oggetti e si può anche saltare la fase ti test, ma il ruolo della factory, 

>o di un qualsiasi "creational" pattern secondo me è più complesso e non va scartata a priori lo sviluppo di test.

si parlava di test d'integrazione vs test unitario,

non di non testare del tutto ... o mi sono perso qualcosa?

[alessandro cinelli]

On Sunday, April 14, 2013, leonardo proietti wrote:

>Un controller funge da collante tra i vari oggetti e si può anche saltare la fase ti test, ma il ruolo della factory, 

>o di un qualsiasi "creational" pattern secondo me è più complesso e non va scartata a priori lo sviluppo di test.

si parlava di test d'integrazione vs test unitario,

non di non testare del tutto ... o mi sono perso qualcosa?

Mi sono perso io, scusate.

Cirpo

 

Il giorno 14 aprile 2013 11:23, alessandro cinelli <alessandr...@gmail.com> ha scritto:

2013/4/14 Eugenio Pombi <eux...@gmail.com>

sono d'accordo con leo e ale.

Aggiungo solo che a volte mi è capitato di usare il DIC per iniettare nella factory alcune dipendenze che fanno parte di una o più delle istanze che vengono ritornate dalla factory stessa.

Mi spiego meglio: mi fa paura quando nella factory uno non deve istanziare solo l'oggetto che vuole ottenere ma anche le sue dipendenze, la factory comincia a quel punto a "sapere troppe cose".

Quello che descrivi tu è un Builder: http://en.wikipedia.org/wiki/Builder_pattern

Comunque non sono totalmente d'accordo con Ale, o meglio: non sono convinto.

Se ho una factory non banale, andrebbe anch'essa testata.

Un controller funge da collante tra i vari oggetti e si può anche saltare la fase ti test, ma il ruolo della factory, o di un qualsiasi "creational" pattern secondo me è più complesso e non va scartata a priori lo sviluppo di test.

"Factory e', a mio modesto parere, un pattern abbastanza di prima generazione (assieme a singleton e registry) che, pur essendo comodi, influiscono abbastanza negativamente sulla pulizia del codice."

Quali altre soluzioni adotteresti?

cirpo

In quel caso delego al DIC la creazione delle dipendenze necessarie agli oggetti che la factory restituisce.

Il giorno 13 aprile 2013 20:10, Alessandro Nadalin <alessandr...@gmail.com> ha scritto:

Risposta veloce: si, sbattitene.

Risposta elucubrata:

Factory e', a mio modesto parere, un pattern abbastanza di prima generazione (assieme a singleton e registry) che, pur essendo comodi, influiscono abbastanza negativamente sulla pulizia del codice. Pero' anche esticazzi: se usati con parsimonia e nel contesto giusto sono comunque delle armi utili ad alcuni fini.

La factory nel tuo caso fa parte di uno strato dell'applicazione che *molto* probabilmente non dovra' essere sottoposto a test unitari per garantirne il funzionamento - un po' come dice Leo per i controller: testare unitariamente un controller (sempre imho) e' utile come un rifugio antiatomico nell'antartico, ovvero si' non ne puoi negare l'utilita' spicciola, ma e' veramente spicciola.

Rientrando nel dominio di utility&configuration, mi premerebbe invece che la factory venisse testata indirettamente attraverso test funzionali o di comportamento.

My 2 cents

2013/4/12 Jacopo Romei <jro...@gmail.com>

Ciao a tutti!

1. Una factory si occupa di prepararmi un oggetto a seconda delle condizioni di contesto.

2. Un factory quindi se ne assume l

--
Hai ricevuto questo messaggio perché sei iscritto al gruppo "PUG Roma" di Google Gruppi.
Visita questo gruppo all'indirizzo http://groups.google.com/group/pug-roma?hl=it-IT.
 
 

--
@cirpo

[Eugenio Pombi]

@cirpo un builder mi risulta una struttura un po'più complessa e articolata ripetto a quello di cui parlavo io. Forse mi sono spiegato male. La classe non si fa carico di "costruire" e forzare un pattern di costruzione per l'oggetto creato, ma si occupa della mera istanziazione.

return new Qualcosa($qualcosAltro)

quel $qualcosaltro non fa della classe un builder.