Metodo di creazione statica: pro e contro rispetto ai costruttori

Question

Metodo di creazione statica: pro e contro rispetto ai costruttori

#1 da (7 voti)
#2 da (7 voti)

10

Quali sono i pro e i contro di avere metodi di creazione di oggetti statici sui costruttori?

class Foo {
  private Foo(object arg) { }

  public static Foo Create(object arg) {
    if (!ValidateParam(arg)) { return null; }
    return new Foo(arg);
  }
}

Pochi a cui riesco a pensare:

Pro:

Restituisce null invece di generare un'eccezione (denominarla TryCreate ). Questo può rendere il codice più conciso e pulito dal lato client. I client raramente si aspettano che un costruttore fallisca.
Crea diversi tipi di oggetti con semantica chiara, ad es. CreatFromName(String name) e CreateFromCsvLine(String csvLine)
Può restituire un oggetto memorizzato nella cache, se necessario, o un'implementazione derivata.

Contro:

Meno codice individuabile, più difficile da scremare.
Alcuni pattern, come la serializzazione o il riflesso, sono più difficili (ad esempio Activator<Foo>.CreateInstance() )

design-patterns

posta dbkk 16.11.2010 - 19:32

fonte

2 risposte

7

Crea è un metodo di fabbrica. Quando ne sento il bisogno, implemento il modello Factory e definisco un'interfaccia per rappresentare il contratto per la creazione dell'oggetto e una classe di implementazione, che viene quindi iniettata dove necessario. Ciò mantiene i vantaggi di spostare la responsabilità di creazione fuori dalla classe, ma evita (o almeno rende più ovvio) i limiti della realizzazione di oggetti all'esterno del costruttore della classe.

risposta data 16.11.2010 - 20:25

fonte

Leggi altre domande sui tag design-patterns

Cosa devo aspettarmi da una valutazione tecnica per C ++? [chiuso] Quali sono alcuni aspetti da tenere presente quando ci si prepara a consegnare un progetto?

score 7 · Accepted Answer

Il più grande svantaggio con " creators " statici è probabilmente la limitazione dell'ereditarietà. Se tu o l'utente della tua libreria ottieni una classe dal tuo Foo , allora Foo::Create() diventa praticamente inutile. Tutta la logica definita dovrà essere riscritta nuovamente nella% ereditata% co_de.

Suggerirei un compromesso: definisci un costruttore con logica di inizializzazione di oggetti banali che non fallisce mai / getta, quindi definisce i creatori con cache, costruzione alternativa ecc. Ciò lascia la possibilità di derivare e tu benefici di avere creatori per una determinata classe.