Attualmente sto imparando a conoscere vari modelli di progettazione orientata agli oggetti. Mi sono imbattuto in un pattern chiamato pattern builder che è fondamentalmente in cui si costruisce un oggetto complesso attraverso l'uso di oggetti semplici che si costruiscono l'un l'altro passo per passo.
La mia domanda è, in quali scenari sarebbe appropriato un tale modello di progettazione? Quale tipo di attività trarrebbe vantaggio da un tale modello di design?
Ogni volta che la creazione di un nuovo oggetto richiede l'impostazione di molti parametri e alcuni di essi (o tutti) sono facoltativi.
es. (per Java ma puoi facilmente trasformarlo in un'altra lingua)
User.builder()
.name("John")
.age(30)
.sex(Sex.MALE)
.build()
invece di
User user = new User();
user.setName("John");
user.setAge(30);
...
Puoi anche creare facilmente oggetti per test con un tale costruttore, ad esempio
User maleUserOver30() {
return User.builder()
.sex(Sex.MALE)
.age(31)
.build();
}
Per iniziare, farò rapidamente contrasto con il modello di fabbrica. Entrambi sono utilizzati per astrarre elementi di creazione dell'oggetto, tuttavia un pattern factory è più appropriato laddove il tipo effettivo dell'oggetto restituito non è noto fino al runtime. Se il tipo di oggetto richiesto è noto in fase di progettazione, trovo le fabbriche inadeguate il più delle volte. Tuttavia, il modello di builder è appropriato per la creazione di classi di tipo singolo e molte fabbriche possono comprendere alcuni elementi del modello di builder.
Dove il modello di build è più utile è quando si ha a che fare con una situazione in cui:
L'esempio più ovvio è per tipi di dati immutabili. Se hai qualche classe di dati che ha dozzine di proprietà / campi, specialmente se alcuni di essi sono opzionali, allora mettere tutti quelli nel costruttore sarà super fastidioso. D'altra parte, se vuoi che quella classe sia immutabile, non puoi istanziare un'istanza e quindi modificare una manciata di proprietà. Esistono soluzioni alternative in cui si dispone di un metodo di "blocco" che in seguito rende le proprietà di sola lettura, ma anche questo è fastidioso. Un costruttore è una buona soluzione al problema.
Allo stesso modo il costruttore che fornisce la verifica / convalida degli errori o può fornire interfacce alternative ai campi interni della classe, come fornire mezzi per specificare unità imperiali o metriche o alcune di esse.
Anche se la classe è mutabile, il pattern builder può ancora fornire un mezzo per assicurarsi che la classe inizi la sua vita in uno stato valido, e i metodi di aggiornamento delle proprietà possono essere usati per mantenere quella validità quando le cose vengono aggiornate.
Se hai classi mutabili che devono essere solo in uno stato valido alcune volte, come un widget GUI che deve essere valido solo quando viene disegnata la finestra, il pattern builder può perdere molto della sua utilità in quelle situazioni.
Leggi altre domande sui tag object-oriented design-patterns