Byggare mönster

Byggmönstret är ett designmönster som är utformat för att ge en flexibel lösning på olika objektskapande problem i objektorienterad programmering . Avsikten med byggarens designmönster är att skilja konstruktionen av ett komplext objekt från dess representation. Det är ett av Gang of Four designmönster .

Översikt

Builders designmönster är ett av designmönsterna som beskriver hur man löser återkommande designproblem i objektorienterad programvara.

Builders designmönster löser problem som:

• Hur kan en klass (samma byggprocess) skapa olika representationer av ett komplext objekt?
• Hur kan en klass som inkluderar att skapa ett komplext objekt förenklas?

Att skapa och montera delarna av ett komplext objekt direkt inom en klass är oflexibelt. Det förbinder klassen att skapa en viss representation av det komplexa objektet och gör det omöjligt att ändra representationen senare oberoende av (utan att behöva ändra) klassen.

Builders designmönster beskriver hur man löser sådana problem:

• Kapsla in att skapa och montera delarna av ett komplext objekt i ett separat Builder- objekt.
• En klass delegerar objektskapande till ett Builder- objekt istället för att skapa objekten direkt.

En klass (samma byggprocess) kan delegera till olika Builder- objekt för att skapa olika representationer av ett komplext objekt.

Definition

Avsikten med Builder-designmönstret är att skilja konstruktionen av ett komplext objekt från dess representation. Genom att göra det kan samma byggprocess skapa olika representationer.

Fördelar

Fördelarna med Builder-mönstret inkluderar:

• Låter dig variera en produkts interna representation.
• Kapslar in kod för konstruktion och representation.
• Ger kontroll över steg i byggprocessen.

Nackdelar

Nackdelarna med Builder-mönstret inkluderar:

• En distinkt ConcreteBuilder måste skapas för varje typ av produkt.
• Builder-klasser måste vara föränderliga.
• Kan försvåra/komplicera beroendeinjektion.

Strukturera

UML klass och sekvensdiagram

Ett exempel på UML-klass och sekvensdiagram för Builder-designmönstret.

I ovanstående UML- klassdiagram skapar och sammanställer inte klassen Director ProductA1- och ProductB1 - objekten direkt. Istället regissören till Builder- gränssnittet för att bygga (skapa och montera) delarna av ett komplext objekt, vilket gör direktören oberoende av vilka konkreta klasser som instansieras (vilken representation som skapas). Klassen Builder1 implementerar Builder- gränssnittet genom att skapa och montera ProductA1- och ProductB1 -objekten. UML - sekvensdiagrammet visar körtidsinteraktionerna: Director -objektet anropar buildPartA() på Builder1- objektet, vilket skapar och sätter samman ProductA1 -objektet. Därefter anropar regissören buildPartB() på Builder1 , som skapar och monterar ProductB1 -objektet.

Klassdiagram

Builder

Abstrakt gränssnitt för att skapa objekt (produkt).

ConcreteBuilder

Tillhandahåller implementering för Builder. Det är ett objekt som kan konstruera andra objekt . Konstruerar och monterar delar för att bygga föremålen.

Exempel

Ett C# exempel:

  

          
          
          
          

            
    
          
          
          
          
    





  

         
         

     





    

          
          

      
    
                           
    





  

      
       
    
          
    

      
    
          
          
    

      
	
		 
	


  

      
    
             
        
           
    
 /// <summary>  /// Representerar en produkt skapad av byggaren  /// </summary>  public  class  Cykel  {  public  string  Make  {  get  ;  set  ;  }  offentlig  sträng  Modell  {  get  ;  set  ;  }  public  int  Höjd  {  get  ;  set  ;  }  offentlig  sträng  Färg  {  get  ;  set  ;  }  public  Bicycle  (  string  make  ,  string  model  ,  string  color  ,  int  height  )  {  Make  =  make  ;  Modell  =  modell  ;  Färg  =  färg  ;  Höjd  =  höjd  ;  }  }  /// <summary>  /// Byggarens abstraktion  /// </summary>  offentligt  gränssnitt  IBicycleBuilder  {  string  Color  {  get  ;  set  ;  }  int  Höjd  {  få  ;  set  ;  }  Cykel  GetResult  ();  }  /// <summary>  /// Concrete builder implementation  /// </summary>  public  class  GTBuilder  :  IBicycleBuilder  {  public  string  Color  {  get  ;  set  ;  }  public  int  Höjd  {  get  ;  set  ;  }  public  Bicycle  GetResult  ()  {  retur  Höjd  ==  29  ?  ny  cykel  (  "GT"  ,  "Avalanche"  ,  Färg  ,  Höjd  )  :  null  ;  }  }  /// <summary>  /// Regissören  /// </summary>  public  class  MountainBikeBuildDirector  {  privat  IBicycleBuilder  _builder  ;  public  MountainBikeBuildDirector  (  IBicycleBuilder  builder  )  {  _builder  =  builder  ;  }  public  void  Construct  ()  {  _builder  .  Färg  =  "Röd"  ;  _byggare  .  Höjd  =  29  ;  }  public  Bicycle  GetResult  ()  {  returnera  detta  .  _byggare  .  GetResult  ();  }  }  public  class  Client  {  public  void  DoSomethingWithBicycles  ()  {  var  director  =  new  MountainBikeBuildDirector  (  ny  GTBuilder  ());  // Director kontrollerar det stegvisa skapandet av produkten och returnerar resultatet.  Cykel  myMountainBike  =  regissör  .  Konstruera  ().  GetResult  ();  }  } 

Direktören sätter ihop en cykelinstans i exemplet ovan och delegerar konstruktionen till ett separat byggobjekt som har getts till direktören av beställaren.

Se även

• Curry
• FluentQueryBuilder