Design: Builder

Question

Ho cercato un buon esempio di un modello di Builder (in C#), ma non riesce a trovare uno o perché non capisco il modello Builder o sto cercando di fare qualcosa che fosse mai inteso. Per esempio, se ho una macchina astratta e metodi di costruzione astratti per creare parti di automobili, dovrei essere in grado di inviare tutte le 30 delle mie scelte al regista, farlo costruire i pezzi che mi servono, quindi costruire la mia automobile. Indipendentemente dal tipo di auto, camion, semi, ecc. Prodotto, dovrei essere in grado di "guidarlo" esattamente nello stesso modo.

Il primo problema è la maggior parte degli esempi di valori di proprietà del codice rigido nelle parti in calcestruzzo, che penso che dovrebbero provenire da un database. Ho pensato che l'idea fosse di inviare le mie scelte al direttore (da una fonte di dati) e fare in modo che il costruttore creasse un prodotto personalizzato basato sui miei dati.

Il secondo problema è che voglio che i metodi builder creino effettivamente le parti, quindi le assegniamo al prodotto, non passiamo stringhe ma parti di prodotto fortemente tipizzate.

Ad esempio, desidero creare un modulo al volo disponendo di un modulo di compilazione per i campi del modulo, inclusa un'etichetta, una sezione di input, la convalida, ecc. In questo modo posso leggere l'oggetto dal mio ORM, controllare fuori i metadati dell'oggetto, passare questo al mio Builder e aggiungere il risultato del controllo utente appena creato al mio modulo web.

Tuttavia, ogni esempio di Builder che trovo ha solo dati hard coded invece di passare le scelte dal codice principale al Builder e dare il via a un prodotto personalizzato. Tutto sembra essere una grande affermazione di un caso statico. Ad esempio, se ho tre parametri con 10 scelte ciascuno, non voglio creare 30 metodi Concrete Builder, voglio creare solo quanto basta per produrre le proprietà richieste dal mio prodotto, che possono essere solo tre.

Sono tentato di avere il direttore solo nel codice principale. Ci dovrebbe essere un modo per determinare automaticamente quale metodo di builder concreto chiamare simile al polymorphism e agli overload dei metodi (sebbene questo sia un pessimo esempio) invece di usare un'istruzione case all'interno del pattern. (Ogni volta che ho bisogno di aggiungere un nuovo tipo di prodotto, ho bisogno di modificare il Director esistente, che è male).

Answer 1

Mi riferisco all'esempio C# nell'articolo di Wikipedia here.

Il primo problema è la maggior parte degli esempi di valori di proprietà del codice rigido nelle parti in calcestruzzo, che penso che dovrebbero provenire da un database. Ho pensato che l'idea fosse di inviare le mie scelte al direttore (da una fonte di dati) e fare in modo che il costruttore creasse un prodotto personalizzato basato sui miei dati.

In questo caso si dovrebbe implementare la classe PizzaBuilder che sa come recuperare i dati da un database. Puoi farlo in diversi modi.

Uno sarebbe fare un HawaiianPizzaBuilder. Quando la classe si inizializza, interroga il database per una pizza hawaiana e recupera la riga. Quindi, quando vengono chiamati i vari metodi di Build (x), esso imposterà le proprietà nel campo corrispondente della riga del database recuperato.

Un altro sarebbe solo fare un PizzaDatabaseBuilder e assicurarsi che quando si inizializza la classe si passa l'ID della riga necessaria per quel tipo di pizza. Per esempio, invece di

waiter.PizzaBuilder = new HawaiianPizzaBuilder(); 

Si utilizza

waiter.PizzaBuilder = new PizzaDatabaseBuilder("Hawaiian"); 

Secondo problema è che voglio i metodi Builder per creare effettivamente le parti poi assegnarli al prodotto, non passa le stringhe ma reale fortemente tipizzato prodotto parti.

Non dovrebbe essere un problema. Quello di cui hai bisogno è un altro tipo di modello Factory/Builder per inizializzare i campi della Pizza. Per esempio

invece di

public override void BuildDough() { pizza.Dough = "pan baked"; } 

si dovrebbe fare qualcosa di simile

public override void BuildDough() { pizza.Dough = new DoughBuilder("pan baked"); } 

o

public override void BuildDough() { pizza.Dough = new PanBakedDoughBuilder(); } 

DoughBuilder può andare in un'altra tabella nel database di compilare correttamente un PizzaDough Classe.

Answer 2

Direi che non è possibile evitare nessuno di questi: avere pochi sovraccarichi per le parti e avere un'istruzione caso/se da qualche parte in cima allo stack. Anche dover modificare il codice quando si aggiunge una nuova classe potrebbe essere la tua unica opzione.

Detto questo, puoi ottenere aiuto con altri schemi, ovvero Factory che potrebbe aiutarti nel processo di costruzione. Anche l'uso sensibile del polimorfismo (ad esempio tutte le parti ereditate da alcuni tipi che siano di classe o di interfaccia) può ridurre la quantità di casi/casi e sovraccarichi.

Spero che questo aiuti.

Answer 3

Per lo più il richiamo di un builder si presenta così:

Car car = new CarBuilder().withDoors(4).withColor("red").withABS(true).build(); 

Answer 4

ci ho mai pensato in questo modo, ma LINQ (il modello, non la sintassi) è in realtà un costruttore, giusto?

È un'interfaccia fluente che crea una query e può creare query in rappresentazioni diverse (SQL, query di oggetti in memoria, query di servizi Web, anche Bart de Smet ha scritto un'implementazione di Linq-to-Excel).