È buona o cattiva pratica fornire classi separate per un oggetto: uno per costruirlo e uno per usarlo?

Ciò che consideri, FooBuilder e Foo sono in realtà parte di un consolidato schema Builder . L'altro approccio menzionato con la creazione di un'istanza di Foo basata su un'istanza esistente è chiamato Modello di prototipo . Entrambe sono ben note alternative alla creazione di oggetti e diversi libri (in particolare "Modelli di progettazione", ovvero GoF) sono stati scritti descrivendoli (non sono sicuro che sia chiaro sul tuo secondo esempio mutevole, quindi confrontiamo da # 1 a # 3 qui)

Ogni modello ha ovviamente i suoi vantaggi e svantaggi e solo tu puoi decidere quale è meglio per la tua situazione specifica. Ad esempio, di solito uso i builder quando ci sono molti modi diversi per inizializzare Foo. Ad esempio, al momento sto lavorando su una classe di generazione di query e molti client la usano in modo diverso per creare oggetti di query. Diversi client vogliono che vengano restituiti campi diversi, alcuni clienti vogliono solo le ultime 10 righe, alcuni vogliono l'ordinamento mentre altri no. Builder è perfetto in quanto può somigliare a questo:

qb = QueryBuilder()
query = qb.fields("name", "address")
          .sort("zip", "asc")
          .limit(10)
          .build()

Quindi più setter, ciascuna istanza di ritorno del builder stesso così da poter fare daisy-chain fondamentalmente serve come un costruttore molto flessibile. Rendere una classe un amico di un'altra classe ha il suo tempo e un posto e potenzialmente questo potrebbe essere uno di quei posti.

In alternativa, è possibile definire Foo come se avesse un costruttore che accetta un set piuttosto complesso di parametri, o potenzialmente si potrebbe definire un'altra classe FooData, che FooBuilder potrebbe inizializzare e passare alla creazione di Foo. Poi di nuovo, forse Foo e FooBuilder essere amici in questo caso non è una cosa così brutta. Tieni presente che quando una classe è amica di un'altra, stai espandendo il limite di incapsulamento, il che potrebbe essere altrettanto grave quanto inserire sempre più codice all'interno di una classe (cioè più codice conosce gli interni)

Alla fine della giornata, potresti pensare e considerare tutte queste diverse opzioni e tutto si ridurrà a 60/40. Se non c'è un vincitore chiaro, puoi sempre lasciare che una moneta scelga il vincitore e vada avanti con essa. Molto probabilmente una delle scelte progettuali funzionerebbe perfettamente e, seguendo le proposte e vedendo il tuo codice in azione, imparerai preziose lezioni per il futuro. A volte, quando ho delle decisioni di progettazione e non riesco a decidere tra A e B, potrei finire per scegliere B e poi, se mai dovessi incontrare una situazione simile, sceglierei deliberatamente l'altra scelta. Il lavoro in entrambi i casi viene completato e il software mi permette di fare ciò che voglio, ma ottieni un sacco di benefici nel vedere le tue decisioni in azione e poter confrontare i due approcci lavorativi , piuttosto piuttosto che discuterne e pensarci.