Design Patterns in iOS — Builder

Builder Pattern Builder Pattern: Separates the construction of a complex object from its representation, so that the same construction process can create different representations. Sometimes there are multiple ways to build an object. If this logic is crammed into a single method of the class responsible for building the object, the code will be riddled with conditional branches. Breaking the construction process into a relationship makes it far easier to manage and reuse. The design pattern that models this relationship is called the Builder. Class Diagram is an abstract interface that declares a method. This method is implemented by to construct the actual product (). has a method that returns the finished to the client. defines a method that tells the instance to . and form an aggregation relationship, meaning is a component that works together with to make the whole pattern function, yet is not responsible for the lifecycle of . This "whole-part" relationship is illustrated by the following sequence diagram: creates an instance of () and an instance of () initialized with , so they can collaborate going forward. When sends the message to , that method sends build-what messages (such as , , and ) to . After 's method returns, sends directly to to retrieve the finished product. In other words, what "knows" is simply what parts each is capable of building. When to Use - When you need to create complex objects that involve various components. The algorithm for creating the object should be independent of how the parts are assembled. A common example is constructing composite objects. - When the construction process needs to produce objects in different ways (e.g., different combinations of components or representations). Builder vs. Abstract Factory The two patterns share some similarities. However, Builder focuses on constructing a complex object step by step — often the same type of object can be built in different ways. Abstract Factory, on the other hand, emphasizes creating families of simple or complex products. Builder returns the product at the last step of a multi-step process, whereas Abstract Factory returns the product immediately. | Builder | Abstract Factory | |---|---| | Constructs complex objects | Constructs simple or complex objects | | Builds the object in multiple steps | Builds the object in a single step | | Builds the object in multiple ways | Builds the object in a single way | | Returns the product at the final step | Returns the product immediately | | Focused on one specific product | Emphasizes a family of products | Usage Example We define a class called with two methods for creating two types of characters — a player and an enemy. is used to build characters; each attribute influences the traits of the character being built. The class diagram showing these static relationships looks like this: is the abstract builder, is the concrete builder, and is the director. defines and , creating player and enemy characters via an instance of . Each method uses a different set of characteristic factors to define the character's traits. is the concrete that actually builds the character based on these factors. Once construction is complete, returns an instance of . A instance has no idea how to build itself into a meaningful character, which is why is needed — it constructs a meaningful character based on the characteristic relationships defined earlier. The instance holds a reference to the target being built, which will be returned to the client once construction is complete. There are several methods for building a character with specific strength, stamina, intelligence, agility, and aggressiveness values. These values affect the defense and attack factors. The abstract defines the default behavior by assigning these values to the target . The method of creates a new instance to be built. is a subclass of that defines the logic for building genuine characters with various related traits. The client creates a and a instance, then sends the and messages to . Summary The Builder pattern helps construct objects that involve various combinations of components and representations. Without this pattern, the — which knows all the details needed to build an object — could easily become a bloated class filled with countless embedded algorithms for building different representations of the same class. Games that design characters with various traits are a perfect use case for this pattern. Rather than defining separate directors to build players and enemies, placing the character-building algorithm inside a concrete is a much more elegant approach. Code All the code in this article can be found on my GitHub .