Creational Design Patterns

1. Factory Method (Factory Method)

The Factory Method pattern delegates the object creation process to subclasses, allowing the superclass to operate without knowing exactly which class the object belongs to. By abstracting the class used for object creation, it provides flexibility and extensibility. The following code example shows a Java implementation of this design pattern.

-> Interface Definition

Let us define an interface named Araba and add a common sur() method to it for all car types.

-> Implementing Classes

Now let us write the Sedan and SUV classes that implement the Araba interface. These classes will implement the sur() method according to their specific characteristics.

-> Abstract Factory Class

Let us define an abstract class named ArabaFabrikasi. The arabaOlustur() method will be left abstract here and will be implemented by subclasses.

-> Concrete Factory Classes

Create two classes, SedanFabrikasi and SUVFabrikasi, that extend the ArabaFabrikasi class. These classes will implement the arabaOlustur() method according to their own logic.

SedanFabrikasi will create a Sedan object, while SUVFabrikasi will create an SUV object.

-> Usage Scenario

This structure prevents the client (the class containing the main method) from directly calling new Sedan() or new SUV(). Instead, the client decides which factory class to invoke and uses the arabaOlustur() method to create the object. This reduces dependencies and increases code flexibility. In summary:

• Factory Method abstracts the object creation process.
• Superclasses do not know which subclass creates the object.
• Dependencies are reduced, and object creation becomes manageable.

This pattern is particularly useful when object types vary. For example, in a system that creates different car types, adding a new car type does not require modifying existing code.

2. Abstract Factory (Abstract Factory) Method

The Abstract Factory provides an interface for creating families of related or dependent objects without specifying their concrete classes. This pattern ensures that products are compatible with each other. The following code example shows a Java implementation of this design pattern.

-> Product Interfaces and Products

First, an interface named Button is defined. This interface contains a paint() method that every button type must implement. Then, two classes implementing this interface are defined: WindowsButton and MacOSButton. These classes specify which operating system the button belongs to.

The Checkbox interface and its operating system-specific implementations are defined similarly. This allows the creation of visual components tailored to different operating systems.

-> Abstract Factory and Sub-Factories

The GUIFactory interface serves as a common factory for the product family. This interface defines methods such as createButton() and createCheckbox() to create the respective components.

The WindowsFactory and MacOSFactory classes implement the GUIFactory interface to produce appropriate buttons and checkboxes for each operating system. Thus, the application obtains visual components suitable for the current operating system.

-> Application Class

The Application class obtains components through the abstract factory and uses them. The key point here is that the application does not need to be aware of the existence of classes such as WindowsButton or MacOSButton. All object creation is performed via the GUIFactory interface.

-> Differences Between Factory Method and Abstract Factory

Factory Method and Abstract Factory are two important approaches among creational design patterns that abstract the object creation process. Both aim to manage object creation through abstract interfaces rather than directly using the new operator. However, they differ in purpose and the level of flexibility they offer.

Factory Method focuses on creating a single type of product. The superclass can operate without knowing which specific type of object will be created, and the object creation process is delegated to subclasses. This allows the system to be extended with new object types. However, a new subclass must be defined for each new product.

Abstract Factory enables the creation of multiple related or dependent objects (a product family) together. For example, in a user interface library, components such as buttons, checkboxes, and menus belonging to the same theme can be produced through a single abstract factory. This approach ensures consistency within the product family.

In summary:

• Factory Method delegates to subclasses the responsibility of deciding which subclass creates the object.
• Abstract Factory provides a common interface for creating multiple objects belonging to a product family.

The key differences between these two patterns are as follows:

• Factory Method focuses on creating a single product, while Abstract Factory aims to create multiple products together.
• Factory Method is structurally simpler, while Abstract Factory provides broader, more holistic solutions.
• Factory Method requires a new class for each product, while Abstract Factory requires a new factory class for each product family.

3. Builder Design Pattern

The Builder design pattern enables the step-by-step and controlled construction of complex objects. Instead of defining all parameters in a single location during object creation, the object is built incrementally. This allows different types of objects to be created using the same construction process. The following code example shows a Java implementation of this design pattern.

-> Product – Araba Class

• The Araba class is the complex object to be constructed.
• Properties: motor, tekerlekSayisi, navigasyon.
• The bilgiYazdir() method prints the current state of the car to the console.
• This class contains no object creation logic—it only holds the properties and behavior of the product.

-> Builder Interface – ArabaBuilder

• This interface defines the steps required to build a car.
• Each step (motorEkle, tekerlekEkle, navigasyonEkle) is defined separately.
• The getAraba() method returns the constructed car.
• This interface allows different types of cars to be built according to the same schema.

-> Concrete Builder – SedanBuilder

• This class is a concrete builder implementing the ArabaBuilder interface.
• It constructs the car object step by step.
• All configurations (motor, tekerlek, navigasyon) are performed here.
• Finally, the completed car object is returned via getAraba().
• Other builders (e.g., SUVBuilder, SporArabaBuilder) can also be defined using the same interface.

-> Director – ArabaDirektoru

• This class controls the builder.
• The ArabaDirektoru determines the order in which steps are executed.
• The olustur() method tells the builder what to do but not how to do it.
• This separates the construction process from the product type.

-> Usage – Main Class

• A Sedan car is selected by choosing the SedanBuilder.
• The ArabaDirektoru determines step by step which components (motor, tekerlek, navigasyon) to use.
• The produced object is retrieved and made ready for use.

-> Difference Between Factory and Builder Design Patterns

Although both the Factory Method and Builder design patterns deal with object creation, they manage this process differently and are preferred in different scenarios. The key difference lies in their focal points and levels of flexibility.

Factory Method delegates the responsibility of deciding which type of object to create to subclasses. This pattern is typically suitable for creating single-step and relatively simple objects. For example, if an application needs to produce either a Sedan or an SUV, this choice can be handled through the Factory. The main advantage of Factory Method is that client code (the part using the object) can work with the object without knowing its exact type.

Builder, on the other hand, provides a much more detailed object creation process. This pattern is used to construct objects step by step, especially for complex objects with many parameters or multiple components. The same construction process can be used to create different types of objects. For example, a computer manufacturer can use the Builder pattern to combine components such as RAM, processor, and storage in different ways to produce both gaming computers and office computers.

In summary:

• Factory abstracts "what is being created,"
• Builder controls "how it is created."

These two patterns can sometimes be used together. A Factory can select the appropriate Builder and then initiate the complex object creation process through that Builder.

4. Prototype Design Pattern

The Prototype pattern allows a new object to be created by copying an existing object. Instead of relying on the new operator to create new objects, this pattern is based on cloning an already existing object.

When is it used?

• When creating complex objects, a prototype object is created once and cloned as needed, avoiding repeated creation of the same structure.
• When the system has many subclasses and creating objects using the new operator becomes expensive.

The following code example shows a Java implementation of this design pattern.

-> Abstract Class Named Shape

• The Shape class contains common properties for all shapes: x and y coordinates and color.
• The clone() method is abstract. Each subclass defines its own clone method.
• The constructor accepts another Shape object and copies its data (i.e., it implements a copy constructor).

-> Rectangle Class (Subclass of Shape)

• The Rectangle class contains its own properties such as width and height.
• It defines its own copy constructor and overrides the clone() method.

-> Circle Class (Another Subclass of Shape)

• The Circle class works on the same principle. The radius field is also copied.
• When clone() is called, the circular object replicates itself.

-> Usage Example

• Instances of circle and rectangle are added to the shapes list.
• Each shape is easily copied using the clone() method.
• This example demonstrates how a single object instance can be cloned to produce multiple copies, allowing the same structure to be reused in different locations.

5. Singleton

The Singleton design pattern ensures that a class has only one instance and provides a global point of access to it. This pattern is ideal for situations where a single point of access is required throughout the application. For example:

• Database connection
• Configuration file access
• Logging system

The following code example shows a Java implementation of this design pattern.

-> Singleton Class Definition

private static Singleton instance;

• A static variable of the class type is defined. This variable holds the single instance of the class.

private Singleton()

• The constructor is defined as private. This prevents external code from calling new Singleton(). No new object can be created from outside the class.

public static Singleton getInstance()

• The only way to access the object is through this static method.
• If the object has not been created yet (instance == null), a new object is created.
• If it has already been created, the same instance is returned. Thus, the same instance is always accessed.