Tukukkk

The below is my understanding of the builder design pattern. Let us say we have a Product class as shown below.

            public class Product

            {

                public string Name { get; set; }



                public string Description { get; set; }



                public int NumberOfProducts { get; set; }



                public decimal Price { get; set; }



                public bool IsDurable { get; set; }

            }

The builder interface:

          public interface IBuilder

          {

            void SetName(string value);



            void SetPrice(decimal value);



            void SetIsDurable(bool value);



            void SetNumberOfProducts(int value);



            void SetDescription(string value);



            Product GetProduct();

        }

A concrete builder that has the setter methods and get the product object.

        public class ConcreteBuilder : IBuilder

        {

            Product product = new Product();



            public Product GetProduct()

            {

                return product;

            }



            public void SetDescription(string value)

            {

                product.Description = value;

            }



            public void SetIsDurable(bool value)

            {

                product.IsDurable = value;

            }



            public void SetName(string value)

            {

                product.Name = value;

            }



            public void SetNumberOfProducts(int value)

            {

                product.NumberOfProducts = value;

            }



            public void SetPrice(decimal value)

            {

                product.Price = value;

            }

        }

In a real-world scenario, the properties of the product should be populated from user inputs and not hardcoded like this. In that case, we need to send the product as well to construct the product object.

        public Product ConstructProduct(IBuilder builder)

        {

            builder.SetDescription("P");

            builder.SetIsDurable(false);

            builder.SetName("My Name");

            builder.SetPrice(10);

            builder.SetNumberOfProducts(5);



            return builder.GetProduct();

        }

Use the builder object in the client as shown below:

public class Client

{

    public void AddProduct()

    {

        ConcreteBuilder builder = new ConcreteBuilder();

        var builtProduct = new Director().ConstructProduct(builder);

        Console.WriteLine(builtProduct.Description);

    }

}

Instead of using the builder pattern as shown above, why can't we use the Product model class itself, like below, when there are many properties to be added in the constructor(to avoid telescoping construction anti-pattern)? If there are any optional properties they can be made nullable.

public class Client

{

    Product _prod;



    public Client(Product prod)

    {

        _prod = prod;

    }



    public void AddProduct()

    {

        // Code to add product

        Console.WriteLine(_prod.Description);

    }

}

When you create a class the primary goal is to reduce complexity of your program. You create a class to hide complexity so that you won’t need to think about it. Sure, you’ll need to think about it when you write the class. But after it’s written, you should be able to forget the details and use the class without any knowledge of its internal workings.

Obviously in the case you mentioned in your question, using the builder pattern increased the complexity and just using the model is the right choice. Because the process of creating your Product object is quite simple.

In other cases creating an object could be a complex operation and you use the builder design pattern to manage this complexity.

Here's an example of real world usage of builder pattern: https://dzone.com/articles/builder-pattern-usage-real