Da quello che ho letto e vissuto, non è una buona pratica avere più di un passo nell'inizializzazione di un oggetto. Questo non va bene perché

1. Devi fare da babysitter a tutti questi oggetti, in modo che i passaggi di inizializzazione richiesti siano completati prima che gli oggetti vengano utilizzati
2. Dovresti aspettarti che chiunque utilizzi il tuo codice possa anche fare da babysitter ai propri oggetti.

Puoi facilmente vedere che il passaggio 1 è abbastanza incline agli errori, in quanto uno potrebbe dimenticare alcuni passaggi o avere difficoltà a tenere traccia di un determinato passaggio completato. E, naturalmente, non dovresti permettere agli utenti del tuo codice di romperlo facilmente, il che significa che dovresti risparmiare loro il passaggio 2.

Tuttavia, ci sono eccezioni note alle prediche precedenti che sono arrivate al mondo dello sviluppo e sono diventate pratiche diffuse e comprovate. La cosa più importante è non consentire l'utilizzo a livello di codice dei prima dei tuoi oggetti da inizializzare correttamente. Ciò implicherebbe l'esistenza di determinati meccanismi di incapsulamento sul ciclo di vita dell'inizializzazione. Ecco alcuni possibili approcci a cui riesco a pensare e i rispettivi casi d'uso nella vita reale:

• Classi di fabbrica

  Una classe factory, (o semplicemente una factory), è una classe separata che espone un singolo metodo ( create se lo desideri), che viene usato per istanziare il tuo oggetto di lavoro. È necessario restituire un'istanza completamente inizializzata e pronta per l'uso della classe, pertanto tutti i passaggi di inizializzazione avvengono all'interno di tale metodo. Ad esempio questo codice (usato C # come lingua):

  public class FooFactory
  {
      public Foo Create()
      {
          Foo foo = new Foo();
          foo.configure(...);
          foo.init(...);
          foo.complete(...);
          return foo;
      }
  }
  

  Questo è considerato uno schema di progettazione, vedi articolo di Wikipedia . Nella maggior parte dei casi il metodo di creazione è chiamato Create o CreateFoo ma puoi scegliere quello che fa per te.

• Iniezione di dipendenza (DI in breve)

  Ciò richiede che tu abbia familiarità con un iniezione di dipendenza e lo impieghi nel tuo progetto. Il framework DI si prenderà cura del passaggio delle istanze completamente inizializzate degli oggetti e alcune implementazioni supportano i passi di inizializzazione post-costruttore che vengono eseguiti prima che l'oggetto sia pronto per l'uso. Questo agisce in modo simile al modello di fabbrica sopra, ma i vantaggi dell'iniezione di dipendenza. Un esempio è il popolare framework Spring (che si rivolge principalmente allo sviluppo Java, ha anche una porta .NET), che consente di specificare entrambi i metodi init e destroy sulla classe. Il metodo init può essere qualsiasi metodo della classe selezionata, quindi puoi facilmente adattare l'intenzione con il metodo create per lavorare con quello.

  <beans ...>
    <bean class="com.mycompany.Foo" init-method="create">
      ...
    </bean>
  </beans>
  

  Vedi questo breve articolo per qualche riferimento.

  Un'alternativa all'approccio precedente è piuttosto specificare una classe statica e un metodo che inizializzerà la tua classe Foo . Per l'esempio seguente, createFoo è un metodo statico della classe FooFactory e restituisce un'istanza di Foo .

  <beans ...>
    <bean class="com.mycompany.FooFactory" 
          factory-method="com.mycompany.FooFactory.createFoo" />
  </beans> 
  

L'elenco precedente non è esaustivo, ci sono altre soluzioni che potrebbero sembrare appropriate in alcuni scenari.