Statico è male, ma per quanto riguarda il modello di fabbrica?

Question

Statico è male, ma per quanto riguarda il modello di fabbrica?

#1 da (12 voti)
#2 da (1 voti)

13

Sono su un progetto TDD, quindi cerco di attenermi il più possibile alle buone pratiche coinvolte in questo tipo di sviluppo. Uno di questi è quello di evitare il più possibile statico e globale.

Sto affrontando questo problema: Ho un "articolo" oggetto che può avere "opzioni" (ulteriori "micro-articoli") collegati ad esso.

Non riesco a capire come avere un buon approccio che non sia controproducente o generare troppe query perché mi troverei in una situazione in cui tutto è così disgiunto che basterò fondamentalmente a creare 1 query per oggetto .

Dalla mia prospettiva attuale, vedo 3 opzioni:

1) Costruisci all'interno dell'articolo:

class Article
{
    //[...]
    public function getArrOption(){
        //Build an array of Options instance.
        //return an array of Options.
    }
}

Pro: Straight forward

Const: manutenibilità: l'oggetto article ora contiene la logica di costruzione per l'oggetto Option. Questo probabilmente porterà alla duplicazione del codice.

2) Usando un'opzioneFactory

class Article
{
    //[...]
    public function getArrOption(){
        return OptionFactory::buildFromArticleId($this->getId());
    }
}

Pro: la logica di creazione non è esclusa dalla classe Article

Const: Sto violando la regola "statico è difficile da deridere", rendendo difficile la verifica della mia classe Article.

3) Separa tutte le logiche.

//Build the array of Option instance in a controller somewhere, using a Factory:
$arrOption = OptionFactory::buildFromArticleId($article->getId());

Pro: l'articolo gestisce solo la sua responsabilità e non si preoccupa del suo link "padre" alle opzioni. Le cose sono davvero disaccoppiate

Const: richiederà più codice all'interno del Controller ogni volta che avrò bisogno di accedere alle Opzioni. Ciò significa che dovrei mai usare una Fabbrica all'interno di un oggetto, e questo mi sembra un po 'utopico ...

Qual è il modo migliore per andare? (Ho perso qualcosa?) grazie.

Modifica:

Per non parlare del fatto che se non riesco a chiamare factory in classe, posso basicamente non usare mai il modello di inizializzazione pigro ...

tdd php static-access

posta FMaz008 07.04.2011 - 21:28

fonte

2 risposte

1

Ecco una citazione dalla carta che sostiene che non hai mai bisogno di metodi statici, che le fabbriche astratte hanno dimostrato di essere confuse e suggerisce un lieve cambiamento di lingua verso l'iniezione di dipendenza come soluzione.

Tight coupling between instances and their classes breaks encapsulation, and, together with the global visibility of static methods, complicates testing. By making dependency injection a feature of the programming language, we can get rid of static methods altogether. We employ the following semantic changes:

(1) Replace every occurrence of a global with an access to an instance variable;

(2) Let that instance variable be automatically injected into the object when it is instantiated.

"Seuss: disaccoppiamento delle responsabilità dai metodi statici per la configurabilità a grana fine"

Link Machine Wayback

risposta data 21.12.2012 - 11:52

fonte

Leggi altre domande sui tag tdd php static-access

Il miglior metodo per implementare una ricerca filtrata Devo rifattorizzare i miei test unitari quando estraggo una classe dal sistema in prova?

score 12 · Accepted Answer

Statico non è "cattivo", è impenetrabile. Puoi ancora usarlo dove il mocking non ha senso.
Non è un pattern Factory, sembra un pattern di repository, anche se potrebbe non esserlo. Factory è dove hai più classi con la stessa interfaccia / classe base e vuoi separare la logica che decide quale classe restituire. Il repository recupera i dati dal proprio repository, estrapolando l'implementazione di quel repository (l'articolo non ha bisogno di sapere se le sue opzioni sono memorizzate nello stesso DB, un altro, un file XML, un file CSV, qualunque cosa).
Hai ignorato la possibilità di assegnare alla classe Article un oggetto ObjectFactory (o Repository o qualunque) nel costruttore su cui può chiamare il metodo buildFromArticle.

Il mio PHP è arrugginito, ma penso che assomigli a questo:

class Article
{
    private $_option_repository;

    public function __construct($option_repository) {
        $_option_repository = $option_repository;
    }

    //[...]

    public function getArrOption(){
        return $_option_repository->buildFromArticleId($this->getId());
    }
}

Penso che questo soddisfi tutti i tuoi professionisti sopra.