the Builder design patter using Java

Here are some reasons why a Java programmer should study the Builder design pattern:

1. Simplified Construction: Allows creating complex objects step-by-step without writing multiple constructors for different configurations.
2. Readable Code: Makes object creation more readable and understandable by clearly defining construction steps in the code.
3. Immutable Objects: Facilitates the creation of immutable objects in Java, enhancing security and reducing unintended changes.
4. Enhanced Maintenance: Simplifies future maintenance by isolating changes in object construction logic to the builder, reducing bugs.
5. Design Flexibility: Provides flexibility to change the internal representation of objects without affecting the client code.

These reasons highlight the practical advantages of the Builder design pattern for Java developers in terms of code maintainability, readability, flexibility, and design.

---

✅ Class Creation Order

1. Product.java – The complex object being built
2. Builder.java – Abstract builder interface
3. ConcreteBuilder.java – Implements the construction steps
4. Director.java – Directs the build process
5. Main.java – Client code for demonstration

---

🔨 1. Product.java

import java.util.ArrayList;
import java.util.List;

// The complex object to be built
public class Product {
    private List<String> parts = new ArrayList<>();

    public void add(String part) {
        parts.add(part);
    }

    public void show() {
        System.out.println("Product parts:");
        for (String part : parts) {
            System.out.println("- " + part);
        }
    }
}

---

🧱 2. Builder.java

// Abstract builder interface
public abstract class Builder {
    public abstract void buildPartA();
    public abstract void buildPartB();
    public abstract Product getResult();
}

---

🧱 3. ConcreteBuilder.java

// Concrete builder implementation
public class ConcreteBuilder extends Builder {
    private Product product = new Product();

    @Override
    public void buildPartA() {
        product.add("PartA");
    }

    @Override
    public void buildPartB() {
        product.add("PartB");
    }

    @Override
    public Product getResult() {
        return product;
    }
}

---

🎯 4. Director.java

// Director that defines the order of building
public class Director {
    public void construct(Builder builder) {
        builder.buildPartA();
        builder.buildPartB();
    }
}

---

🚀 5. Main.java

// Client code demonstrating usage of the Builder pattern
public class Main {
    public static void main(String[] args) {
        Director director = new Director();
        Builder builder = new ConcreteBuilder();

        director.construct(builder);
        Product product = builder.getResult();

        product.show(); // Output: Product parts: PartA, PartB
    }
}

---

💡 Summary

Class	Responsibility
Product	Complex object that gets constructed
Builder	Abstract interface for building parts
ConcreteBuilder	Builds and assembles the product step-by-step
Director	Controls the construction process using a builder
Main	Demonstrates how to use the Builder pattern

---

⚙️ Key Characteristics of Builder in Java

• Builds complex objects in step-by-step fashion.
• Separates the construction and representation.
• Can reuse the same construction process to build different representations.

Builder Design Pattern in C#

This is a C# implementation of the Builder design pattern, based on the Gang of Four's structure. Each class is placed in a separate file, and all code lines are commented.

🔧 Product.cs

public class Product
{
    private List<string> _parts = new List<string>(); // List to store product parts

    public void Add(string part)
    {
        _parts.Add(part);
    }

    public void Show()
    {
        Console.WriteLine("Product Parts:");
        foreach (string part in _parts)
        {
            Console.WriteLine("- " + part);
        }
    }
}

🔧 Builder.cs

public abstract class Builder
{
    public abstract void BuildPartA(); // Step to build Part A
    public abstract void BuildPartB(); // Step to build Part B
    public abstract Product GetResult(); // Returns the final product
}

🔧 ConcreteBuilder.cs

public class ConcreteBuilder : Builder
{
    private Product _product = new Product(); // The product instance being built

    public override void BuildPartA()
    {
        _product.Add("PartA"); // Adds PartA to the product
    }

    public override void BuildPartB()
    {
        _product.Add("PartB"); // Adds PartB to the product
    }

    public override Product GetResult()
    {
        return _product; // Returns the fully built product
    }
}

🔧 Director.cs

public class Director
{
    public void Construct(Builder builder)
    {
        builder.BuildPartA(); // Instruct builder to build Part A
        builder.BuildPartB(); // Instruct builder to build Part B
    }
}

🔧 Program.cs

class Program
{
    static void Main(string[] args)
    {
        Director director = new Director(); // Initializes the director
        Builder builder = new ConcreteBuilder(); // Initializes a concrete builder

        director.Construct(builder); // Directs the builder to build the product

        Product product = builder.GetResult(); // Retrieves the final product
        product.Show(); // Displays the product parts
    }
}

💡 Console Output

Product Parts:
- PartA
- PartB

Builder Pattern in C++

Below is a C++ implementation of the Builder design pattern, a Creational pattern, following the Gang of Four (GoF) structure. Each class is placed in its own .h and .cpp files, with the order of creation designed to avoid dependency issues.

---

✅ Class Creation Order (to avoid dependency errors)

1. Product (The complex object being built)
2. Builder (Abstract builder interface)
3. ConcreteBuilder (Implements construction steps)
4. Director (Orchestrates the building process)
5. Client Code (main.cpp)

---

🔧 1. Product.h

#ifndef PRODUCT_H
#define PRODUCT_H

#include <string>
#include <vector>

class Product {
private:
    std::vector<std::string> parts;

public:
    void addPart(const std::string& part);
    void show() const;
};

#endif // PRODUCT_H

---

🔧 Product.cpp

#include "Product.h"
#include <iostream>

void Product::addPart(const std::string& part) {
    parts.push_back(part);
}

void Product::show() const {
    std::cout << "Product parts: ";
    for (const auto& part : parts) {
        std::cout << part << " ";
    }
    std::cout << std::endl;
}

---

🧱 2. Builder.h

#ifndef BUILDER_H
#define BUILDER_H

#include "Product.h"

// Abstract Builder
class Builder {
public:
    virtual void buildPartA() = 0;
    virtual void buildPartB() = 0;
    virtual Product* getResult() = 0;
    virtual ~Builder() {}
};

#endif // BUILDER_H

---

🧱 3. ConcreteBuilder.h

#ifndef CONCRETEBUILDER_H
#define CONCRETEBUILDER_H

#include "Builder.h"

// Concrete Builder
class ConcreteBuilder : public Builder {
private:
    Product* product;

public:
    ConcreteBuilder();
    ~ConcreteBuilder();

    void buildPartA() override;
    void buildPartB() override;
    Product* getResult() override;
};

#endif // CONCRETEBUILDER_H

---

🧱 ConcreteBuilder.cpp

#include "ConcreteBuilder.h"

ConcreteBuilder::ConcreteBuilder() {
    product = new Product();
}

ConcreteBuilder::~ConcreteBuilder() {
    delete product;
}

void ConcreteBuilder::buildPartA() {
    product->addPart("PartA");
}

void ConcreteBuilder::buildPartB() {
    product->addPart("PartB");
}

Product* ConcreteBuilder::getResult() {
    return product;
}

---

🎯 4. Director.h

#ifndef DIRECTOR_H
#define DIRECTOR_H

#include "Builder.h"

// Director
class Director {
public:
    void construct(Builder* builder);
};

#endif // DIRECTOR_H

---

🎯 Director.cpp

#include "Director.h"

void Director::construct(Builder* builder) {
    builder->buildPartA();
    builder->buildPartB();
}

---

👨‍💻 5. main.cpp

#include <iostream>
#include "Director.h"
#include "ConcreteBuilder.h"

int main() {
    Director director;
    ConcreteBuilder builder;

    director.construct(&builder);
    Product* product = builder.getResult();

    product->show();

    return 0;
}

---

🧠 Summary & Explanation

Class/File	Role
Product	The complex object that is built step by step.
Builder	Abstract interface that defines methods for building the parts.
ConcreteBuilder	Implements the building steps and returns the final product.
Director	Controls the order of building steps, using a Builder.
main.cpp	The client code that puts it all together.

---

✅ Benefits of the Builder Pattern in C++

• Encapsulates complex construction logic.
• Supports multiple representations of a product.
• Promotes separation of concerns (product vs. construction steps).

Abstract Factory Design Pattern in PHP 8.1

Here's a detailed example of the Abstract Factory Design Pattern in PHP 8.1 with explanations for each class, method, and variable. The code is divided into multiple files, each representing a class, and an index.php file to demonstrate the usage of the pattern.

Step-by-Step Class Creation Order

1. Product Interfaces
   • AbstractProductA.php
   • AbstractProductB.php
2. Concrete Products
   • ProductA1.php
   • ProductA2.php
   • ProductB1.php
   • ProductB2.php
3. Abstract Factory Interface
   • AbstractFactory.php
4. Concrete Factories
   • ConcreteFactory1.php
   • ConcreteFactory2.php
5. Client
   • Client.php
6. Index File
   • index.php

Product Interfaces

AbstractProductA.php

<?php
interface AbstractProductA {
    public function usefulFunctionA(): string;
}
?>
  

AbstractProductA: Defines an interface for a type of product object.

AbstractProductB.php

<?php
interface AbstractProductB {
    public function usefulFunctionB(): string;
    public function anotherUsefulFunctionB(AbstractProductA $collaborator): string;
}
?>
  

AbstractProductB: Defines an interface for another type of product object and a method that collaborates with AbstractProductA.

Concrete Products

ProductA1.php

<?php
require_once 'AbstractProductA.php';

class ProductA1 implements AbstractProductA {
    public function usefulFunctionA(): string {
        return "The result of the product A1.";
    }
}
?>
  

ProductA1: Concrete implementation of AbstractProductA.

ProductA2.php

<?php
require_once 'AbstractProductA.php';

class ProductA2 implements AbstractProductA {
    public function usefulFunctionA(): string {
        return "The result of the product A2.";
    }
}
?>
  

ProductA2: Another concrete implementation of AbstractProductA.

ProductB1.php

<?php
require_once 'AbstractProductB.php';
require_once 'AbstractProductA.php';

class ProductB1 implements AbstractProductB {
    public function usefulFunctionB(): string {
        return "The result of the product B1.";
    }

    public function anotherUsefulFunctionB(AbstractProductA $collaborator): string {
        $result = $collaborator->usefulFunctionA();
        return "The result of the B1 collaborating with ({$result})";
    }
}
?>
  

ProductB1: Concrete implementation of AbstractProductB.

ProductB2.php

<?php
require_once 'AbstractProductB.php';
require_once 'AbstractProductA.php';

class ProductB2 implements AbstractProductB {
    public function usefulFunctionB(): string {
        return "The result of the product B2.";
    }

    public function anotherUsefulFunctionB(AbstractProductA $collaborator): string {
        $result = $collaborator->usefulFunctionA();
        return "The result of the B2 collaborating with ({$result})";
    }
}
?>
  

ProductB2: Another concrete implementation of AbstractProductB.

Abstract Factory Interface

AbstractFactory.php

<?php
interface AbstractFactory {
    public function createProductA(): AbstractProductA;
    public function createProductB(): AbstractProductB;
}
?>
  

AbstractFactory: Defines an interface for creating abstract product objects.

Concrete Factories

ConcreteFactory1.php

<?php
require_once 'AbstractFactory.php';
require_once 'ProductA1.php';
require_once 'ProductB1.php';

class ConcreteFactory1 implements AbstractFactory {
    public function createProductA(): AbstractProductA {
        return new ProductA1();
    }

    public function createProductB(): AbstractProductB {
        return new ProductB1();
    }
}
?>
  

ConcreteFactory1: Concrete implementation of AbstractFactory to create ProductA1 and ProductB1.

ConcreteFactory2.php

<?php
require_once 'AbstractFactory.php';
require_once 'ProductA2.php';
require_once 'ProductB2.php';

class ConcreteFactory2 implements AbstractFactory {
    public function createProductA(): AbstractProductA {
        return new ProductA2();
    }

    public function createProductB(): AbstractProductB {
        return new ProductB2();
    }
}
?>
  

ConcreteFactory2: Concrete implementation of AbstractFactory to create ProductA2 and ProductB2.

Client

Client.php

<?php
require_once 'AbstractFactory.php';

class Client {
    private AbstractProductA $productA;
    private AbstractProductB $productB;

    public function __construct(AbstractFactory $factory) {
        $this->productA = $factory->createProductA();
        $this->productB = $factory->createProductB();
    }

    public function run(): void {
        echo $this->productB->usefulFunctionB() . "\n";
        echo $this->productB->anotherUsefulFunctionB($this->productA) . "\n";
    }
}
?>
  

Client: Uses the abstract factory to create and use the product objects. Demonstrates interaction between products.

Index File

index.php

<?php
require_once 'ConcreteFactory1.php';
require_once 'ConcreteFactory2.php';
require_once 'Client.php';

function main() {
    echo "Testing with ConcreteFactory1:\n";
    $factory1 = new ConcreteFactory1();
    $client1 = new Client($factory1);
    $client1->run();

    echo "\nTesting with ConcreteFactory2:\n";
    $factory2 = new ConcreteFactory2();
    $client2 = new Client($factory2);
    $client2->run();
}

main();
?>
  

index.php: Demonstrates the usage of the Abstract Factory pattern by creating clients with different factories and running their methods.

What You Should See When Running the Code

Testing with ConcreteFactory1:
The result of the product B1.
The result of the B1 collaborating with (The result of the product A1.)

Testing with ConcreteFactory2:
The result of the product B2.
The result of the B2 collaborating with (The result of the product A2.)
  

This output demonstrates that the Client can work with any factory, creating different products and using their methods interchangeably.

Java Creational Design Factory

🚀 **Master the Abstract Factory Design Pattern in Java!** 🎥

Abstract Factory Pattern in Java

Pattern Category: Creational
Pattern Name: Abstract Factory
Programming Language: Java
Target Audience: First-year college students

---

Purpose

The Abstract Factory pattern provides an interface for creating families of related or dependent objects without specifying their concrete classes.

---

Class/File Creation Order (to avoid dependency errors):

1. AbstractProductA.java
2. AbstractProductB.java
3. ProductA1.java
4. ProductA2.java
5. ProductB1.java
6. ProductB2.java
7. AbstractFactory.java
8. ConcreteFactory1.java
9. ConcreteFactory2.java
10. Client.java
11. Main.java

---

Class Descriptions and Code

1. AbstractProductA.java

// Abstract product A declares an interface for a type of product object
public interface AbstractProductA {
    void interact();
}

• Interface: AbstractProductA — base for all ProductA types.
• Method: interact() — interaction behavior; defined later in concrete classes.

---

2. AbstractProductB.java

// Abstract product B declares an interface for a type of product object
public interface AbstractProductB {
    void interactWith(AbstractProductA a);
}

• Interface: AbstractProductB — base for all ProductB types.
• Method: interactWith(AbstractProductA a) — defines dependency on ProductA.

---

3. ProductA1.java

public class ProductA1 implements AbstractProductA {
    @Override
    public void interact() {
        System.out.println("ProductA1 interacting");
    }
}

• Concrete Product: Implements AbstractProductA.
• Method: Implements interaction logic for variant A1.

---

4. ProductA2.java

public class ProductA2 implements AbstractProductA {
    @Override
    public void interact() {
        System.out.println("ProductA2 interacting");
    }
}

• Concrete Product: Implements AbstractProductA.
• Method: Implements interaction logic for variant A2.

---

5. ProductB1.java

public class ProductB1 implements AbstractProductB {
    @Override
    public void interactWith(AbstractProductA a) {
        System.out.print("ProductB1 interacting with ");
        a.interact();
    }
}

• Concrete Product: Implements AbstractProductB.
• Method: Calls a.interact() showing inter-product behavior.

---

6. ProductB2.java

public class ProductB2 implements AbstractProductB {
    @Override
    public void interactWith(AbstractProductA a) {
        System.out.print("ProductB2 interacting with ");
        a.interact();
    }
}

• Concrete Product: Implements AbstractProductB.
• Method: Similar to ProductB1 but represents a different product variant.

---

7. AbstractFactory.java

// Abstract Factory declares an interface for creating abstract products A and B
public interface AbstractFactory {
    AbstractProductA createProductA();
    AbstractProductB createProductB();
}

• Interface: Factory for creating families of products A and B.
• Methods:
  • createProductA() — produces AbstractProductA
  • createProductB() — produces AbstractProductB

---

8. ConcreteFactory1.java

public class ConcreteFactory1 implements AbstractFactory {
    @Override
    public AbstractProductA createProductA() {
        return new ProductA1();
    }

    @Override
    public AbstractProductB createProductB() {
        return new ProductB1();
    }
}

• Concrete Factory: Implements creation of ProductA1 and ProductB1.

---

9. ConcreteFactory2.java

public class ConcreteFactory2 implements AbstractFactory {
    @Override
    public AbstractProductA createProductA() {
        return new ProductA2();
    }

    @Override
    public AbstractProductB createProductB() {
        return new ProductB2();
    }
}

• Concrete Factory: Implements creation of ProductA2 and ProductB2.

---

10. Client.java

// Client uses only interfaces declared by AbstractFactory and products
public class Client {
    private AbstractProductA productA;
    private AbstractProductB productB;

    public Client(AbstractFactory factory) {
        // The factory creates the concrete products
        productA = factory.createProductA();
        productB = factory.createProductB();
    }

    public void run() {
        productB.interactWith(productA);
    }
}

• Class: Depends only on abstract interfaces.
• Constructor: Receives a factory to instantiate related products.
• Method: run() demonstrates interaction between products.

---

11. Main.java

public class Main {
    public static void main(String[] args) {
        System.out.println("Using ConcreteFactory1:");
        AbstractFactory factory1 = new ConcreteFactory1();
        Client client1 = new Client(factory1);
        client1.run();

        System.out.println("\nUsing ConcreteFactory2:");
        AbstractFactory factory2 = new ConcreteFactory2();
        Client client2 = new Client(factory2);
        client2.run();
    }
}

• Entry Point: Demonstrates how the Abstract Factory is used at runtime.
• Switching Factories: Shows that client code remains unchanged when using different product families.

---

Summary

The Abstract Factory pattern allows you to create families of related objects without binding your code to their concrete classes. This example uses the exact naming and structure from the Gang of Four book, making it ideal for educational purposes.

Benefits:

• Promotes consistency among products.
• Isolates concrete classes.
• Simplifies code updates for new families.

---

Abstract Factory Pattern in C#

Below is a C# implementation of the Abstract Factory design pattern, a Creational pattern, following the Gang of Four (GoF) structure. Each class is placed in its own file and created in an order that avoids dependency issues.

---

Class Creation Order

To avoid dependency issues, create the classes in this order:

1. AbstractProductA & AbstractProductB (Abstract Products)
2. ConcreteProductA1, ConcreteProductA2, ConcreteProductB1, ConcreteProductB2 (Concrete Products)
3. AbstractFactory (Factory Interface)
4. ConcreteFactory1 & ConcreteFactory2 (Factory Implementations)
5. Client Code (Program.cs)

---

1. Abstract Products (IAbstractProductA.cs & IAbstractProductB.cs)

IAbstractProductA.cs

namespace AbstractFactoryPattern
{
    // Abstract Product A
    public interface IAbstractProductA
    {
        void Use();
    }
}

IAbstractProductB.cs

namespace AbstractFactoryPattern
{
    // Abstract Product B
    public interface IAbstractProductB
    {
        void Use();
    }
}

Explanation

IAbstractProductA and IAbstractProductB define the interfaces for two types of products.
Each product type has a Use() method, which will be implemented by concrete products.

---

2. Concrete Products

ConcreteProductA1.cs

using System;

namespace AbstractFactoryPattern
{
    // Concrete Product A1
    public class ConcreteProductA1 : IAbstractProductA
    {
        public void Use()
        {
            Console.WriteLine("Using ConcreteProductA1");
        }
    }
}

ConcreteProductA2.cs

using System;

namespace AbstractFactoryPattern
{
    // Concrete Product A2
    public class ConcreteProductA2 : IAbstractProductA
    {
        public void Use()
        {
            Console.WriteLine("Using ConcreteProductA2");
        }
    }
}

ConcreteProductB1.cs

using System;

namespace AbstractFactoryPattern
{
    // Concrete Product B1
    public class ConcreteProductB1 : IAbstractProductB
    {
        public void Use()
        {
            Console.WriteLine("Using ConcreteProductB1");
        }
    }
}

ConcreteProductB2.cs

using System;

namespace AbstractFactoryPattern
{
    // Concrete Product B2
    public class ConcreteProductB2 : IAbstractProductB
    {
        public void Use()
        {
            Console.WriteLine("Using ConcreteProductB2");
        }
    }
}

Explanation

ConcreteProductA1, ConcreteProductA2 implement IAbstractProductA.
ConcreteProductB1, ConcreteProductB2 implement IAbstractProductB.
These represent different product variations.

---

3. Abstract Factory (IAbstractFactory.cs)

namespace AbstractFactoryPattern
{
    // Abstract Factory Interface
    public interface IAbstractFactory
    {
        IAbstractProductA CreateProductA();
        IAbstractProductB CreateProductB();
    }
}

Explanation:
Defines CreateProductA() and CreateProductB(), which will be implemented by concrete factories.

---

4. Concrete Factories

ConcreteFactory1.cs

namespace AbstractFactoryPattern
{
    // Concrete Factory 1
    public class ConcreteFactory1 : IAbstractFactory
    {
        public IAbstractProductA CreateProductA()
        {
            return new ConcreteProductA1();
        }

        public IAbstractProductB CreateProductB()
        {
            return new ConcreteProductB1();
        }
    }
}

ConcreteFactory2.cs

namespace AbstractFactoryPattern
{
    // Concrete Factory 2
    public class ConcreteFactory2 : IAbstractFactory
    {
        public IAbstractProductA CreateProductA()
        {
            return new ConcreteProductA2();
        }

        public IAbstractProductB CreateProductB()
        {
            return new ConcreteProductB2();
        }
    }
}

Explanation:
ConcreteFactory1 creates ConcreteProductA1 and ConcreteProductB1.
ConcreteFactory2 creates ConcreteProductA2 and ConcreteProductB2.

---

5. Client Code (Program.cs)

using System;

namespace AbstractFactoryPattern
{
    class Program
    {
        static void Main(string[] args)
        {
            // Create a factory of type 1
            IAbstractFactory factory1 = new ConcreteFactory1();
            IAbstractProductA productA1 = factory1.CreateProductA();
            IAbstractProductB productB1 = factory1.CreateProductB();

            productA1.Use(); // Output: Using ConcreteProductA1
            productB1.Use(); // Output: Using ConcreteProductB1

            // Create a factory of type 2
            IAbstractFactory factory2 = new ConcreteFactory2();
            IAbstractProductA productA2 = factory2.CreateProductA();
            IAbstractProductB productB2 = factory2.CreateProductB();

            productA2.Use(); // Output: Using ConcreteProductA2
            productB2.Use(); // Output: Using ConcreteProductB2
        }
    }
}

---

Final Explanation

1. Abstract Products (IAbstractProductA, IAbstractProductB): Define interfaces for different types of products.
2. Concrete Products: Implement the abstract product interfaces.
3. Abstract Factory: Declares factory methods for creating products.
4. Concrete Factories: Implement factory methods to produce different products.
5. Client Code: Uses the abstract factory to create product families.

---

Key Takeaways

• ✅ Encapsulation: The client is independent of concrete product classes.
• ✅ Scalability: Easily add new product families without modifying existing code.
• ✅ Consistency: Ensures related products are created together.

Would you like a downloadable version of this file or to have it combined with the C++/PHP HTML examples into a single learning package?

Below is a C++ implementation of the Abstract Factory design pattern, which is a Creational pattern, following the Gang of Four (GoF) structure. Each class is placed in its own file and created in an order that avoids dependency issues.

---

Class Creation Order

To avoid dependency errors, create the classes in this order:

1. AbstractProductA & AbstractProductB (Abstract Products)
2. ConcreteProductA1, ConcreteProductA2, ConcreteProductB1, ConcreteProductB2 (Concrete Products)
3. AbstractFactory (Factory Interface)
4. ConcreteFactory1 & ConcreteFactory2 (Factory Implementations)
5. Client Code (main.cpp)

---

1. AbstractProductA.h & AbstractProductB.h (Abstract Products)

AbstractProductA.h

#ifndef ABSTRACTPRODUCTA_H
#define ABSTRACTPRODUCTA_H

// Abstract Product A
class AbstractProductA {
public:
    virtual void use() = 0; // Pure virtual function
    virtual ~AbstractProductA() {} // Virtual destructor
};

#endif // ABSTRACTPRODUCTA_H

AbstractProductB.h

#ifndef ABSTRACTPRODUCTB_H
#define ABSTRACTPRODUCTB_H

// Abstract Product B
class AbstractProductB {
public:
    virtual void use() = 0;
    virtual ~AbstractProductB() {} // Virtual destructor
};

#endif // ABSTRACTPRODUCTB_H

Explanation

AbstractProductA and AbstractProductB define the interfaces for the two types of products. Each abstract product contains a use() method, which will be implemented by concrete products.

---

2. Concrete Products

ConcreteProductA1.h

#ifndef CONCRETEPRODUCTA1_H
#define CONCRETEPRODUCTA1_H

#include "AbstractProductA.h"
#include <iostream>

// Concrete Product A1
class ConcreteProductA1 : public AbstractProductA {
public:
    void use() override {
        std::cout << "Using ConcreteProductA1" << std::endl;
    }
};

#endif // CONCRETEPRODUCTA1_H

ConcreteProductA2.h

#ifndef CONCRETEPRODUCTA2_H
#define CONCRETEPRODUCTA2_H

#include "AbstractProductA.h"
#include <iostream>

// Concrete Product A2
class ConcreteProductA2 : public AbstractProductA {
public:
    void use() override {
        std::cout << "Using ConcreteProductA2" << std::endl;
    }
};

#endif // CONCRETEPRODUCTA2_H

ConcreteProductB1.h

#ifndef CONCRETEPRODUCTB1_H
#define CONCRETEPRODUCTB1_H

#include "AbstractProductB.h"
#include <iostream>

// Concrete Product B1
class ConcreteProductB1 : public AbstractProductB {
public:
    void use() override {
        std::cout << "Using ConcreteProductB1" << std::endl;
    }
};

#endif // CONCRETEPRODUCTB1_H

ConcreteProductB2.h

#ifndef CONCRETEPRODUCTB2_H
#define CONCRETEPRODUCTB2_H

#include "AbstractProductB.h"
#include <iostream>

// Concrete Product B2
class ConcreteProductB2 : public AbstractProductB {
public:
    void use() override {
        std::cout << "Using ConcreteProductB2" << std::endl;
    }
};

#endif // CONCRETEPRODUCTB2_H

Explanation

ConcreteProductA1, ConcreteProductA2 implement AbstractProductA.
ConcreteProductB1, ConcreteProductB2 implement AbstractProductB.
These represent different product variations.

---

3. AbstractFactory.h (Abstract Factory Interface)

#ifndef ABSTRACTFACTORY_H
#define ABSTRACTFACTORY_H

#include "AbstractProductA.h"
#include "AbstractProductB.h"

// Abstract Factory Interface
class AbstractFactory {
public:
    virtual AbstractProductA* createProductA() = 0;
    virtual AbstractProductB* createProductB() = 0;
    virtual ~AbstractFactory() {} // Virtual destructor
};

#endif // ABSTRACTFACTORY_H

Explanation:
Defines createProductA() and createProductB(), which will be implemented by concrete factories.

---

4. Concrete Factories

ConcreteFactory1.h

#ifndef CONCRETEFACTORY1_H
#define CONCRETEFACTORY1_H

#include "AbstractFactory.h"
#include "ConcreteProductA1.h"
#include "ConcreteProductB1.h"

// Concrete Factory 1
class ConcreteFactory1 : public AbstractFactory {
public:
    AbstractProductA* createProductA() override {
        return new ConcreteProductA1();
    }

    AbstractProductB* createProductB() override {
        return new ConcreteProductB1();
    }
};

#endif // CONCRETEFACTORY1_H

ConcreteFactory2.h

#ifndef CONCRETEFACTORY2_H
#define CONCRETEFACTORY2_H

#include "AbstractFactory.h"
#include "ConcreteProductA2.h"
#include "ConcreteProductB2.h"

// Concrete Factory 2
class ConcreteFactory2 : public AbstractFactory {
public:
    AbstractProductA* createProductA() override {
        return new ConcreteProductA2();
    }

    AbstractProductB* createProductB() override {
        return new ConcreteProductB2();
    }
};

#endif // CONCRETEFACTORY2_H

Explanation:
ConcreteFactory1 creates ConcreteProductA1 and ConcreteProductB1.
ConcreteFactory2 creates ConcreteProductA2 and ConcreteProductB2.

---

5. main.cpp (Client Code)

#include <iostream>
#include "ConcreteFactory1.h"
#include "ConcreteFactory2.h"

int main() {
    // Create a factory of type 1
    AbstractFactory* factory1 = new ConcreteFactory1();
    AbstractProductA* productA1 = factory1->createProductA();
    AbstractProductB* productB1 = factory1->createProductB();

    productA1->use(); // Output: Using ConcreteProductA1
    productB1->use(); // Output: Using ConcreteProductB1

    // Create a factory of type 2
    AbstractFactory* factory2 = new ConcreteFactory2();
    AbstractProductA* productA2 = factory2->createProductA();
    AbstractProductB* productB2 = factory2->createProductB();

    productA2->use(); // Output: Using ConcreteProductA2
    productB2->use(); // Output: Using ConcreteProductB2

    // Cleanup
    delete productA1;
    delete productB1;
    delete factory1;

    delete productA2;
    delete productB2;
    delete factory2;

    return 0;
}

---

Final Explanation

1. Abstract Products (AbstractProductA & AbstractProductB): Define interfaces for different types of products.
2. Concrete Products: Implement the abstract products.
3. Abstract Factory: Declares factory methods for creating products.
4. Concrete Factories: Implement factory methods to produce different products.
5. Client Code: Uses the abstract factory to create product families.

---

Key Takeaways

• ✅ Encapsulation: The client is independent of concrete product classes.
• ✅ Scalability: Easily add new product families without modifying existing code.
• ✅ Consistency: Ensures related products are created together.