Metodo di fabbrica rispetto al modello di progettazione di fabbrica

Question

Metodo di fabbrica rispetto al modello di progettazione di fabbrica

#1 da (11 voti)

4

Conosco i metodi Simple Factory Idiom, Factory Method e Abstract Factory Design.

Ma ho due situazioni che non sono sicuro di come chiamare (esempio di codice PHP):

class User {
  public static function LoadUserById($id) {
    $objUser = new User();
    //load details from DB
    return $objUser;
  }
}

class UserFactory {
   public function Create($id) {
    $objUser = new User();
    //load details from DB
    return $objUser;
   }
}

Quali sono queste due situazioni? Fabbriche semplici (linguaggio di programmazione) o si chiamano qualcos'altro?

È una buona pratica denominare la classe UserFactory? Non è questo qualcosa che potrebbe essere confuso con il modello di progettazione di una fabbrica? Dovrei usare un nome diverso per questo come UserFinder?

Quando penso a Factory Design Pattern, penso sempre ad esempi dove ci sono famiglie di componenti derivati da una classe genitore, ma chiaramente non è il caso qui.

design-patterns

posta danidacar 16.09.2013 - 09:25

fonte

1 risposta

Leggi altre domande sui tag design-patterns

Qual è la definizione di puntatore? [duplicare] La mia architettura ha un problema con le viste che richiedevano informazioni da oggetti diversi. Come posso risolvere questo?

score 11 · Answer 1

Il precedente è definito una violazione del principio di responsabilità singola :) La tua classe User non dovrebbe conoscere o preoccuparsi del database. È un anti-modello, semmai.

Ci dovrebbe essere un solo motivo per cambiare la classe User - ed è che il concetto di utente all'interno della tua applicazione potrebbe cambiare.

Implementare LoadUserById sulla classe User significa che dovresti riscrivere quella classe per ragioni totalmente indipendenti - come passare da MySQL a PostgreSQL, per esempio, che non ha nulla a che fare con l'utente in quanto tale . Tali dettagli di implementazione dovrebbero essere separati, esternalizzati.

Quest'ultimo è più di un modello di deposito di fabbrica, credo. UserRepository potrebbe essere un nome abbastanza ragionevole per tale classe.

Si noti che il ruolo di una Fabbrica consiste nel creare oggetti, specialmente quando questa attività è complessa e implica una logica avanzata che si desidera mantenere in un unico posto.

Il recupero dei dati dal database è una responsabilità diversa. Non si tratta di creare un oggetto in sé: il vero obiettivo è ottenere dati per quell'oggetto (o "idratarlo", come alcuni insistono).