Design mode 03:builder Generator mode (create mode)

Builder Builder Mode (Create-mode)

The origin of builder mode
Suppose you create a house facility in the game, the building is made up of several parts, and the parts are richly varied.
If you use the most intuitive design method, the changes in each part of the House will lead to the re-revision of the building.

Motive (motivation)
In the software system, sometimes faced with the creation of "a complex object", it is usually composed of the sub-objects of each part with certain algorithms, and because of the change of the requirements, the parts of this complex object often face drastic changes, but the algorithm that combines them is very stable.
How to deal with this change? How to provide a "encapsulation mechanism" to isolate the "various parts of complex objects" change, so that the system "stable building algorithm" does not change with the need to change?

Intentions (Intent)
Separating the construction of a complex object from its representation allows the same build process to create different representations-design mode GoF

Game Framework Builder application, sample code is just a framework, no specific implementation

 Public Abstract classhouse{} Public Abstract classdoor{} Public Abstract classwall{} Public Abstract classwindows{} Public Abstract classfloor{} Public Abstract classhouseceiling{}

 Public Abstract class romanhouse:house{}  Public class romandoor:door{}  Public class romanwall:wall{}  Public class romanwindows:windows{}  Public class romanfloor:floor{}  Public class romanhouseceiling:houseceiling{}

 Public Abstract classbuilder{ Public Abstract voidBuilddoor ();  Public Abstract voidBuildwall ();  Public Abstract voidbuildwindows ();  Public Abstract voidBuildfloor ();  Public Abstract voidbuildhouseceiling ();  Public AbstractHouse Gethouse ();}

 Public Abstract classromanbuilder:builder{ Public Override voidBuilddoor () {} Public Override voidBuildwall () {} Public Override voidbuildwindows () {} Public Override voidBuildfloor () {} Public Override voidbuildhouseceiling () {} Public OverrideHouse Gethouse () {}}

 Public class gamemanager{    publicstatic house Createhouse (builder Builder)//  The build process is a relatively stable place in the system     {        Builder. Buiilddoor ();        Builder. Buiilddoor ();                Builder. Buildwall ();        Builder. Buildwall ();        Builder. Buildwall ();        Builder. Buildwall ();                Builder. Buildwindows ();        Builder. Buildwindows ();                Builder. Buildfloor ();                Builder. Buildhouseceiling ();         return Bilder. Gethouse ();    }}

classapp{ Public Static voidMain () {//House House = Gamemanager.createhouse (Romanbuilder builder); //You can also build house by reading the configuration file, reflection        stringassemblyname=configurationsettings["builderassembly"];//Assembly Name        stringBuildername = configurationsettings["Builderclass"];//class nameAssembly Assembly=Assembly.Load (AssemblyName); Type T=Assembly.                GetType (Buildername); Builder Builder=activator.createinstance (t); House House=Gamemanager.createhouse (builder); }}

Open Close principle: Open for extension, close for modification

Several key points of the builder model:
The builder mode is primarily used to "build a complex object in steps". In this, "step-by" is a stable algorithm, while the parts of complex objects change frequently.
Where is the change point, where is it packaged? The--builder pattern is mainly to deal with the frequent demand changes of "complex object parts". The disadvantage is that it is difficult to cope with the demand change of the "step-up construction algorithm".
Abstract Factory mode solves the requirement change of "series object", and the builder mode solves the requirement change of "object part".
The builder mode is typically used in combination with the composite pattern.

Design mode 03:builder Generator mode (create mode)