Una caratteristica comune che abbiamo è una relazione disponibile in più formati. Ad esempio, un report sui prezzi sarà disponibile come foglio di calcolo Excel per consentire al team di marketing di modificare i numeri, come un report in PDF per un aspetto piacevole per i clienti esterni e come testo ASCII per inviare via email / SMS al personale di vendita .
Otteniamo ciò disaccoppiando la creazione dell'output con il report usando un'interfaccia come
public interface DocumentMaker{
void makeSectionHeader( String s );
void makeParagraph( String s );
void makeFootnote( String s );
...
String make();
}
et cetera. La stessa logica del report chiama quindi questi metodi senza sapere quale sarà il formato finale del report.
Finiamo per riferirci a questo modello come al "modello costruttore" (e spesso lo usiamo come nostro nome) ma non sembra che sia un'applicazione appropriata del modello. Il modello di builder è descritto come :
Instead of using numerous constructors, the builder pattern uses another object, a builder, that receives each initialization parameter step by step and then returns the resulting constructed object at once.
Tuttavia, non siamo veramente interessati all'oggetto restituito, e spesso tutte le varianti restituiscono lo stesso tipo (ad esempio String ).
In realtà, sembra più vicino al modello di strategia che è descritto come:
The strategy pattern defines a family of algorithms, encapsulates each algorithm, and makes the algorithms interchangeable within that family. Strategy lets the algorithm vary independently from clients that use it
Questo suona più come stiamo facendo.
Sebbene un collega suggerisca che sono fabbriche astratte :
The client doesn't know (or care) which concrete objects it gets from each of these internal factories, since it uses only the generic interfaces of their products. This pattern separates the details of implementation of a set of objects from their general usage and relies on object composition, as object creation is implemented in methods exposed in the factory interface.
Quindi, ciò che stiamo facendo è appropriato per chiamare il "modello di builder"? In caso contrario, esiste un modello più appropriato per chiamarlo?