Forem: Pranil Tunga

Adapter Design Pattern

Pranil Tunga — Tue, 16 May 2023 19:18:00 +0000

The majority of the patterns that fall under the "creational" gamma category, or patterns that are primarily focused on the creation of structures, were covered in our previous blogs. Now that it is time to move on to the very next category, we will discuss the patterns that fall under the "structural" gamma category. So let's take a look at the "Adapter Design Pattern," which is our first structural pattern.

What is this pattern about?

You might be confused by reading the overall definition of this pattern, but don't worry; in the following sections, we will try to simplify it and explain it using a variety of examples. This pattern primarily focuses on interfaces, and its main goal is to obtain a new interface from an existing interface that you already have.

Now imagine you are traveling internationally with an electrical device. Since we are aware that voltages and current parameters can vary from country to country and we are unable to really replace the entire electrical device, what we do is purchase an adapter that can adjust the voltage and other factors to allow us to use our devices without any problems.

The same principles apply to programming as well; occasionally, we can introduce a component into our system that can provide an additional interface to an already-existing interface, which we can then modify in accordance with business logic.

Why Adapters?

Let's say that when developing systems, we occasionally need to conform existing interfaces to the interfaces needed for new functionalities. The piece of software we write to accomplish this is simply called the "Adapter."

The main purpose of adapters is to enable legacy applications to work with new codebases so that we can reuse the existing code or library through newly created adapters.

Let's use an illustration to better understand:

namespace DesignPatterns.Structural.AdapterPattern
{
    public enum EmployeeTypes
    {
        Salaried,
        Contract
    }

    public class Employee
    {
        public string Name { get; set; }
        public double Salary { get; set; }

        public virtual void Display()
        {
            Console.WriteLine($"{Name} is employee");
        }
    }

    public class EmployeeAdapter : Employee
    {
        public EmployeeAdapter(string Name, EmployeeTypes employeeType)
        {
            this.Name = Name;
            var calculator = new EmployeeSalaryCalculator();
            this.Salary = calculator.Calculate(employeeType);
        }

        public override void Display()
        {
            Console.WriteLine($"{Name} is working on {Salary} per month");
        }
    }

    public class EmployeeSalaryCalculator
    {
        public double Calculate(EmployeeTypes type)
        {
            switch (type)
            {
                case EmployeeTypes.Salaried: return 10000;
                case EmployeeTypes.Contract: return 7000;
                default: return 0;
            }
        }
    }

    public class AdapterPattern
    {
        public static void Main(string[] args)
        {
            Employee john = new EmployeeAdapter("John", EmployeeTypes.Salaried);
            john.Display();

            Employee doe = new EmployeeAdapter("Doe", EmployeeTypes.Contract);
            doe.Display();
        }
    }
}

As you can see, we have a class called "Employee" that acts as the employee's representation in our system, as well as a class called "EmployeeSalaryCalculator" that calculates the employee's salary. As you can see, we have now added a new class called "EmployeeAdapter" that acts as a sort of intermediary and adds extra functionality between these two classes. In other words, we are adding a new interface to modify an existing interface in order to achieve new functionality, and the new class is in charge of figuring out salaries for various employee types, so we are merely introducing a new structure to support new features.

The class "EmployeeSalaryCalculator" is an "Adaptee" in the example above, which is the class that an adapter uses to mold data, and the class "EmployeeAdapter" is an actual adapter class that we have added to support salary calculations for a variety of types.

Types of Roles in Adapter Patterns:

ITarget

This typically represents the interface in the codebase that the client wants to target or use.

Adaptee

This stands for the piece of code or interface that needs to be modified in order to accommodate the new changes.

Adapter

In terms of the Adaptee, this represents the class that actually implements the ITarget interface, making it the class most in charge of updating the structure or, to be more precise, introducing the new functionalities so that Adaptee can be used as an ITarget after being processed by an adapter.

Request

The lifecycle for adapter acceptance begins with this, which typically represents the actual operation the client wants to accomplish. It is also the stage at which an adapter's functionality is determined.

SpecificRequest

This determines what needs to be changed in Adaptee in order to achieve new functionality since it represents the actual implementation of the request's functionality in the Adaptee.

Different Implementations:

Adapters can be implemented in a variety of ways. Since we already looked at one type of implementation in the example above, let's move on to some other ways to define an adapter.

Generic Adapter Implementation:

This is another way we can make adapters; typically, we encourage passing generics to adapter classes in order to write more readable code. This adapter functions similarly to others, but people tend to follow these conventions for better readability and genericness.

Example:

namespace DesignPatterns.Structural.GenericAdapterPattern
{
    public abstract class Employee
    {
        public string Name { get; set; }
        public double Salary { get; set; }

        public abstract void CalculateSalary();
    }

    public class SalariedEmployee : Employee
    {
        public override void CalculateSalary()
        {
            Salary = 10000;
            Console.WriteLine($"{Name} working full time with ${Salary} per month");
        }
    }

    public class ContractBasisEmployee : Employee
    {
        public override void CalculateSalary()
        {
            Salary = 7000;
            Console.WriteLine($"{Name} working on contract basis with ${Salary} per month");
        }
    }

    public class EmployeeAdapter<T> where T : Employee, new()
    {
        public static void Display(string Name)
        {
            var obj = new T();
            obj.Name = Name;
            obj.CalculateSalary();
        }
    }

    public class AdapterPattern
    {
        public static void Main(string[] args)
        {
            EmployeeAdapter<SalariedEmployee>.Display("John");
            EmployeeAdapter<ContractBasisEmployee>.Display("Doe");
        }
    }
}

As you can see, we are now using generics and passing classes directly to the EmployeeAdapter class, allowing it to select the class to use for runtime salary calculation.

Also, you can make a single method generic if you are not comfortable making the entire class generic and only want to make a specific method generic. This will allow you to introduce other things into the same class if you so choose.

This is a method to accomplish that:

public class EmployeeAdapter
{
    public static void Display<T>(string Name) where T : Employee, new()
    {
        var obj = new T();
        obj.Name = Name;
        obj.CalculateSalary();
    }
}

public class AdapterPattern
{
    public static void Main(string[] args)
    {
        EmployeeAdapter.Display<SalariedEmployee>("John");
        EmployeeAdapter.Display<ContractBasisEmployee>("Doe");
    }
}

That concludes this blog's discussion of the "Adapter Pattern," the first pattern in the "Structural" category. However, in future blogs, we will discuss other structural patterns as well. Follow along.

Happy Coding…!!!

Singleton Pattern

Pranil Tunga — Tue, 16 May 2023 19:13:27 +0000

In this blog post, we will give a brief overview of the singleton pattern, which is the most contentious pattern but still has some applications that can help us optimize our code.

Why Singleton?

We can use this pattern when some code components in real-world scenarios are intended to be declared only once. For instance, since factories do not have states, as we discussed, we can declare them as singletons and share a single instance of that factory across the entire code base, which will handle object creation everywhere. You can also use this when you want to limit the number of constructor calls.

This pattern can also be used when you want to create a single object that supports lazy initialization and thread safety and prevents users from creating multiple copies of the same object.

Let’s understand with an example.

namespace DesignPatterns.Singleton
{

    public interface IWeather
    {
        public (double min, double max) GetWeather(string city);
    }

    public class Weather : IWeather
    {
        private double _min, _max;

        public Weather()
        {
            //we are using thread.sleep to mimic
            //the behavior but you can call actual
            //weather API here to get minimum & maximum temperature
            Thread.Sleep(200);
            _min = 29.59;
            _max = 31.60;
        }

        public (double min, double max) GetWeather(string city)
        {
            return (_min, _max);
        }
    }
}

As you can see from the code snippet above, this class is in charge of calling the weather API to obtain the minimum and maximum weather temperatures. We then use the "GetWeather" function, which returns a tuple, to return those values. However, as you can see, we are calling an API in the constructor of a Weather class, which means that each time we create a new object, it will also call the constructor and an API. This can lead to a number of issues because, typically, weather APIs are rate-limited and only certain requests are permitted to be made within a given window of time. However, if we use them frequently, there is a chance that we will go over the limit and incur additional fees as a result of the extra API calls.

You might be wondering how we can address this issue. Making that class a singleton allows us to share a single instance across all requests and eliminates the need for additional calls, which is the straightforward solution.

namespace DesignPatterns.Singleton
{

    public interface IWeather
    {
        public (double min, double max) GetWeather(string city);
    }

    public class WeatherSingleton : IWeather
    {
        private double _min, _max;

        private WeatherSingleton()
        {
            //we are using thread.sleep to mimic
            //the behavior but you can call actual
            //weather API here to get minimum & maximum temperature
            Thread.Sleep(200);
            _min = 29.59;
            _max = 31.60;
        }

        public (double min, double max) GetWeather(string city)
        {
            return (_min, _max);
        }

        private static Lazy<WeatherSingleton> _instance = new Lazy<WeatherSingleton>(() => new WeatherSingleton());
        public static WeatherSingleton Instance => _instance.Value;
    }
}

As you can see, we have now made our constructor private, exposed the static field so that anyone can obtain a single instance, and initialized the constructor in a lazy way so that it will only be called if someone accesses the static "Instance" field.

Why does everyone hate “Singleton”?

Since we are aware that singletons are closely coupled with the underlying data, this makes them less testable, which is the single biggest problem with singletons. Let's use an example to better understand this. Suppose you have a repository pointing to a particular database, and you are writing tests against it. In some cases, you might need to hardcode data in some of the tests, but what if the data in the database were to change? If so, you will also need to update your tests, which is a time-consuming task in real life. In TDD-based systems, tests serve as the cornerstone for writing code and should not be altered. This is the singleton pattern's well-known limitation. In other words, once we start hardcoding the reference to the same instance of the specific component everywhere, we can't really change it to something else.

The issue is that you need to introduce DI & mocks even for the simplest solutions, making this issue completely irrelevant. However, this is not a problem that we cannot solve; we can do so by introducing the DI libraries and then replacing the actual DB with some mock.

Monostate Singleton

By focusing on the name, we can deduce that this pattern shares some characteristics with the singleton design pattern in that "a class sharing the same state amongst all instances is called a monostate class."

namespace DesignPatterns.MonostateSingleton
{
    public class SelectedColor
    {
        private static string _color;

        public string Color
        {
            get => _color;
            set => _color = value;
        }

        public override string ToString()
        {
            return $"You have selected {_color} color";
        }
    }

    public class TestMonostate
    {
        public static void Main(string[] args)
        {
            SelectedColor clr = new SelectedColor();
            clr.Color = "Orange";

            SelectedColor clr2 = new SelectedColor();
            Console.WriteLine(clr2);
        }
    }
}

As you can see, we're using static fields in the class and updating them with regular properties, which update the static values that are shared by all instances. As a result, we are sharing a class's state with all of its instances.

Per-Thread Singleton

When we need a single object per thread that is shared across all of the operations carried out by that thread, such as when we need a singleton per thread, we can use the Pre-Thread singleton.

namespace DesignPatterns.PerThreadSingleton
{
    public class RandomValue
    {
        public int Value;

        private RandomValue()
        {
            Console.WriteLine($"Creating new instance for theread : {Thread.CurrentThread.ManagedThreadId}");
            Value = new Random().Next(int.MaxValue);
        }

        private static ThreadLocal<RandomValue> _instance = new ThreadLocal<RandomValue>(() => new RandomValue());
        public static RandomValue Instance => _instance.Value;
    }

    public class TestClass
    {
        public static void Main(string[] args)
        {
            var thread1 = new Thread(() =>
            {
                Console.WriteLine("Thread1 random value : " + RandomValue.Instance.Value);
            });

            thread1.Start();

            var thread2 = new Thread(() =>
            {
                Console.WriteLine("Thread2 1st random value : " + RandomValue.Instance.Value);
                Console.WriteLine("Thread2 2nd random value : " + RandomValue.Instance.Value);
            });

            thread2.Start();
        }
    }
}

Therefore, as you can see, we are creating a singleton instance per thread in this case, which is why the constructor's print statement was called twice. Additionally, to demonstrate that we only create one instance per thread, take a look at the output. Both instances inside of thread 2 are returning the same values, proving that even if we create two instances in “thread2,” only one object is created, and since we execute both operations on a single thread, this object is shared amongst all operations.

This concludes our blog on singleton design patterns; in subsequent blogs, we will examine the following patterns under the creational category.

Happy Coding…!!!

Prototype design pattern

Pranil Tunga — Tue, 16 May 2023 19:09:09 +0000

As a result, in our previous blog, we examined the information regarding the factory pattern and why and when it should be used. We'll be looking at the prototype design pattern in this article, so let's dive in and try to understand it.

Overview:

This pattern focuses primarily on copying or cloning existing objects in our memory. so that they can be used more effectively and multiple copies can be used by users to perform multiple operations.

The majority of things in many real-life scenarios aren't made from scratch; instead, they're added to or taken away from an existing prototype or model. computers, as an example. There are probably some situations in programming as well where we need to expand the current object prototype so that it can be altered and used to carry out different tasks. In other words, we are reusing the current designs.

What is a prototype?

In our codebase, a "prototype" is a fully or partially existing type. (In most programming languages, "classes" are regarded as the object's prototype; because C is a procedural language, "structs" are used instead.)

Why the prototype pattern?

Imagine that we already have a prototype that is built using the "factory" pattern, but we want to perform multiple operations, or variations, on that prototype. In order to perform variations, we need multiple copies of the object, which is where the "Prototype Design Pattern" comes in very handy.

Let's look at an example to try to understand why we need this.

public class Employee : ICloneable
{
    public Employee(string name, string[] skills)
    {
        Name = name;
        Skills = skills;
    }

    public string Name { get; set; }
    public string[] Skills { get; set; }

    public object Clone()
    {
        return new Employee(Name, Skills);
    }

    public override string ToString()
    {
        return $"{Name} is good in {string.Join(",", Skills)}";
    }
}

public class CloneObjectsMain
{
    public static void Main(string[] args)
    {
        var johnDoe = new Employee("John Doe", new string[] { "Cooking", "Singing" });

        var johnDummy = (Employee)johnDoe.Clone();
        johnDummy.Name = "John Dummy";
        johnDummy.Skills = new string[] { "Coding" };

        Console.WriteLine(johnDoe);
        Console.WriteLine(johnDummy);
    }
}

Here, we have a class called "Employee" that contains the name of an employee and an array called "Skills" that the employee can use to store their skills. You'll see that the Employee class uses the ICloneable interface to copy the object; in our case, this is fine, but if you later decide to make a class for skills and use its array, you'll need to modify the new class to inherit ICloneable and provide an implementation for the Clone() method. Otherwise, the new class will share the same reference and run the risk of changing an existing object. As a result, we can say that ICloneable performs a “shallow copy.” Another drawback is that, if you pay close attention, you’ll notice that the Clone() method returns “object” as its return type, which means that each time you clone, you must explicitly typecast the object to the required type. This can result in a number of errors, or the user may accidentally mismatch the types while explicitly converting since there is no restriction on that.

Let's see how to implement the prototype class so that we can deeply copy our objects in order to solve this issue.

namespace DesignPatterns.PrototypePattern
{
    public abstract class EmployeePrototype
    {
        public abstract Employee DeepCopy();
    }

    public class Employee : EmployeePrototype
    {
        public Employee(string name, string[] skills)
        {
            Name = name;
            Skills = skills;
        }

        public string Name { get; set; }
        public string[] Skills { get; set; }

        public override Employee DeepCopy()
        {
            return new Employee(Name, Skills);
        }

        public override string ToString()
        {
            return $"{Name} is good in {string.Join(",", Skills)}";
        }
    }

    public class PrototypePatternMain
    {
        public static void Main(string[] args)
        {
            var johnDoe = new Employee("John Doe", new string[] { "Cooking", "Singing" });

            var johnDummy = johnDoe.DeepCopy();
            johnDummy.Name = "John Dummy";
            johnDummy.Skills = new string[] { "Coding" };

            Console.WriteLine(johnDoe);
            Console.WriteLine(johnDummy);
        }
    }
}

Since the "DeepCopy()" abstract method returns "Employee," we don't need to worry about explicit conversion. Currently, we are using the "abstract" class to specify the prototype of the Employee class, which contains the abstract method.

But as you can see, each class must have its own prototype, which is very time-consuming when dealing with multiple classes in real-world situations. Instead, we can use generics in this case, and since we have marked all of the methods as abstract, we can also use abstract classes to create interfaces.

namespace DesignPatterns.PrototypePattern
{
    public interface IPrototype<T>
    {
        T DeepCopy();
    }

    public class Employee : IPrototype<Employee>
    {
        public Employee(string name, string[] skills)
        {
            Name = name;
            Skills = skills;
        }

        public string Name { get; set; }
        public string[] Skills { get; set; }

        public Employee DeepCopy()
        {
            return new Employee(Name, Skills);
        }

        public override string ToString()
        {
            return $"{Name} is good in {string.Join(",", Skills)}";
        }
    }

    public class PrototypePatternMain
    {
        public static void Main(string[] args)
        {
            var johnDoe = new Employee("John Doe", new string[] { "Cooking", "Singing" });

            var johnDummy = johnDoe.DeepCopy();
            johnDummy.Name = "John Dummy";
            johnDummy.Skills = new string[] { "Coding" };

            Console.WriteLine(johnDoe);
            Console.WriteLine(johnDummy);
        }
    }
}

Now that deep cloning or copying of existing objects is possible, we can use the same interface across all existing classes.

However, let's assume that in real-world situations, we deal with a hierarchy of classes that we must copy. In that case, we must be concerned with a number of issues, such as exposing appropriate constructors, requiring that every class inherit the "IPrototype" interface, and ensuring that every class implements the "DeepCopy()" method. These issues may be more difficult to implement and can be time-consuming.

You might now be wondering how we can solve or simplify this, and the best option might be to use "Prototype Inheritance."

What is “prototype inheritance”?

By using the DeepCopy() method, we can easily duplicate an existing prototype. However, if someone tried to inherit the prototype, we would also have to inherit the "IPrototype" interface for that type, where we would have to again provide implementation for its methods. This would also repeat the base class creation, which could be problematic if your hierarchy contains 10 to 20 classes.

Let's use an illustration to better understand:

namespace DesignPatterns.PrototypePattern
{
    public interface IPrototype<T>
    {
        T DeepCopy();
    }

    public class Skill : IPrototype<Skill>
    {
        public string SkillName;

        public Skill(string skillName)
        {
            SkillName = skillName;
        }

        public Skill DeepCopy()
        {
            return new Skill(SkillName);
        }
    }

    public class Employee : IPrototype<Employee>
    {
        public string Name;
        public Skill Skill;

        public Employee(string name, Skill skill)
        {
            Name = name;
            Skill = skill;
        }

        public Employee DeepCopy()
        {
            return new Employee(Name, Skill.DeepCopy());
        }
    }

    public class PartTimeEmployee : Employee, IPrototype<PartTimeEmployee>
    {
        public int DailyWorkingHours;
        public PartTimeEmployee(string name, Skill skill, int dailyWorkingHours)
            : base(name, skill)
        {
            DailyWorkingHours = dailyWorkingHours;
        }

        PartTimeEmployee IPrototype<PartTimeEmployee>.DeepCopy()
        {
            return new PartTimeEmployee(Name, Skill.DeepCopy(), DailyWorkingHours);
        }
    }
}

As you can see, we are creating the "PartTimeEmployee" class here based on the "Employee" class that already exists. If you pay attention to the parameters "Name" and "Skill," you'll notice that we are performing the same operation while deep copying multiple times.

return new Employee(Name, Skill.DeepCopy());

And

return new PartTimeEmployee(Name, Skill.DeepCopy(), DailyWorkingHours);

are largely the same, and maintaining the same thing in a larger hierarchy of 10 to 20 classes would be disastrous. This might not be an efficient solution, and it also cannot be scaled.

Let's now look at a solution to this issue.

namespace DesignPatterns.PrototypePattern
{
    public interface IPrototype<T>
        where T : new()
    {
        void CopyInto(T destination);

        T DeepCopy()
        {
            T obj = new T();
            CopyInto(obj);
            return obj;
        }
    }

    public class Skill : IPrototype<Skill>
    {
        public string SkillName;

        public Skill() { }

        public Skill(string skillName)
        {
            SkillName = skillName;
        }

        public void CopyInto(Skill destination)
        {
            destination.SkillName = SkillName;
        }
    }

    public class Employee : IPrototype<Employee>
    {
        public string Name;
        public Skill Skill;

        public Employee() { }

        public Employee(string name, Skill skill)
        {
            Name = name;
            Skill = skill;
        }

        public void CopyInto(Employee destination)
        {
            destination.Name = Name;
            destination.Skill = ((IPrototype<Skill>)Skill).DeepCopy();
        }
    }

    public class PartTimeEmployee : Employee, IPrototype<PartTimeEmployee>
    {
        public int DailyWorkingHours;

        public PartTimeEmployee() { }

        public PartTimeEmployee(string name, Skill skill, int dailyWorkingHours)
            : base(name, skill)
        {
            DailyWorkingHours = dailyWorkingHours;
        }

        public void CopyInto(PartTimeEmployee destination)
        {
            base.CopyInto(destination);
            destination.DailyWorkingHours = DailyWorkingHours;
        }
    }
}

As you can see, we are now using it correctly. We are also cloning each class within its boundaries, and in the "CopyTo()" method of the "PartTimeEmployee" class, you can see that we are using the CopyTo() method from the base class. This is the benefit we can obtain from using the generic approach in this case.

Additionally, you can use the extension methods on each class to create the purposeful calls if you want to expose better-looking functions as an API for user convenience.

However, for the purposes of this blog, we'll stick with the approach we just discussed. You can also use recursive generics to optimize the code, just as we did in the Builder Pattern earlier.

Is there any other approach?

This time, we'll talk about how this pattern is used in real-world situations. In real-world situations, the original object is serialized, and while the object is being deserialized, it is copied and its state is maintained. Let's quickly look at an example of how we can accomplish this.

namespace DesignPatterns.PrototypePattern
{
    public static class Extensions
    {
        public static T DeepCopy<T>(this T obj)
        {
            using (var ms = new MemoryStream())
            {
                var formatter = new BinaryFormatter();
                formatter.Serialize(ms, obj);
                ms.Position = 0;

                return (T)formatter.Deserialize(ms);
            }
        }
    }

    [Serializable]
    public class Skill
    {
        public string SkillName;

        public Skill(string skillName)
        {
            SkillName = skillName;
        }
    }

    [Serializable]
    public class Employee
    {
        public string Name;
        public Skill Skill;

        public Employee(string name, Skill skill)
        {
            Name = name;
            Skill = skill;
        }

        public override string ToString()
        {
            return $"{Name} is good in {Skill.SkillName}";
        }
    }

    [Serializable]
    public class PartTimeEmployee : Employee
    {
        public int DailyWorkingHours;

        public PartTimeEmployee(string name, Skill skill, int dailyWorkingHours)
            : base(name, skill)
        {
            DailyWorkingHours = dailyWorkingHours;
        }

        public override string ToString()
        {
            return $"{base.ToString()} and is spending {DailyWorkingHours} hours daily to improve.";
        }
    }

    public class MainClass
    {
        public static void Main(string[] args)
        {
            var partTimeEmp = new PartTimeEmployee("John Doe", new Skill("Coding"), 10);
            var copyOfObject = partTimeEmp.DeepCopy();

            //Just to demonstrate that it is not mutating
            //original object (i.e. we are deep copying)
            copyOfObject.Name = "Jack Reacher";
            copyOfObject.DailyWorkingHours = 15;
            copyOfObject.Skill = new Skill("Cooking");

            Console.WriteLine(partTimeEmp);
            Console.WriteLine(copyOfObject);
        }
    }
}

You'll see that we are now using a stream to serialize and deserialize the object, which allows us to create a copy of the object without changing the original. This is because the extension method we are using is generic and can be attached to any type of object. You'll also notice that we've added the [Serializable] attribute to our classes so we can serialize them in streams.

You can also use JsonSerialization, XmlSerialization, or Reflection to create an entirely new copy of an object as additional serialization and deserialization methods.

This concludes our discussion of the current pattern; in our subsequent blog, we will discuss the subsequent pattern under the "Creational" gamma category.

Happy Coding...!!!

“Abstract” Factory Design Pattern

Pranil Tunga — Tue, 16 May 2023 19:03:25 +0000

In our previous blog post, we looked at how to write factory methods to create objects; however, in this post, we'll examine how an actual abstract factory is implemented, its benefits, and how it can help us customize object creation.

Why do we use this?

In order for the programmer or developer using the object to further extend it and create their own implementations, the abstract factory can be used to return abstract objects, i.e., objects that have only been partially created.

Let's use an illustration to better understand:

public class Coordinates
{
    public Coordinates(double x, double y)
    {
        this.x = x;
        this.y = y;
    }

    public double x { get; set; }
    public double y { get; set; }
}

public class CoordinatesFactory
{
    public Coordinates Create(double x, double y)
    {
        return new Coordinates(x, y);
    }
}

Here, you can see that we have a simple factory implementation where we are using another class to implement an object and the "Create()" method of that Factory is returning a "Coordinates" object, which can lead to tight coupling.

To solve this, we usually use Abstract implementations of an object using the abstract factory; let's look at an example to see how this works.

Let's say we have a business requirement that requires us to create an employee object with monthly and hourly pay, but the user should be able to specify the difference in salaries when creating objects.

And this is where Abstract Factory comes in handy because we can simply return an abstraction, and later users can simply extend that abstraction to specify salaries in their very own class implementations. Let's see how this works.

namespace Factory.AbstractFactory
{
    public interface ISalariedEmployee
    {
        void Create(string Name);
    }

    public interface IHourlyPaiedEmployee
    {
        void Create(string Name);
    }

    public class SalariedEmployee : ISalariedEmployee
    {
        public void Create(string Name)
        {
            Console.WriteLine($"{Name} is working as a full time employee!");
        }
    }

    public class HourlyPaiedEmployee : IHourlyPaiedEmployee
    {
        public void Create(string Name)
        {
            Console.WriteLine($"{Name} is working as a part time employee on hourly basis!");
        }
    }
}

We have now created the necessary interfaces that we can use to create objects. We can now create a Factory for Employee and use these interfaces to return while object creation.

Let's start building our factory:

public interface ISalariedEmployeeFactory
{
    ISalariedEmployee Generate();
}

public interface IHourlyPaidEmployeeFactory
{
    IHourlyPaidEmployee Generate();
}

public class SalariedEmployeeFactory : ISalariedEmployeeFactory
{
    public ISalariedEmployee Generate()
    {
        Console.WriteLine($"This can be used to create salaried employee!");
        return new SalariedEmployee();
    }
}

public class HourlyPaidEmployeeFactory : IHourlyPaidEmployeeFactory
{
    public IHourlyPaidEmployee Generate()
    {
        Console.WriteLine($"This can be used to create hourly paid employee!");
        return new HourlyPaidEmployee();
    }
}

As you can see, the Generate() method of class "HourlyPaidEmployeeFactory" returns the "IHourlyPaidEmployee" interface, allowing us to create N numbers of classes based on the two interfaces that we have. For instance, if we later decided to create an employee who can be salaried but who can also be paid based on the extra hours he worked overtime, we can simply create a new class and utilize existing functionalities to achieve that, and we can also utilize the existing factories to achieve those requirements.

In order to extend existing factories, abstract factories can be very helpful. They can also be used to return abstract objects that can be extended further.

Combined source code for usage of the above abstract factory:

namespace Factory.AbstractFactory
{
    public interface ISalariedEmployee
    {
        void Create(string Name);
    }

    public interface IHourlyPaidEmployee
    {
        void Create(string Name);
    }

    public class SalariedEmployee : ISalariedEmployee
    {
        public void Create(string Name)
        {
            Console.WriteLine($"{Name} is working as a full time employee!");
        }
    }

    public class HourlyPaidEmployee : IHourlyPaidEmployee
    {
        public void Create(string Name)
        {
            Console.WriteLine($"{Name} is working as a part time employee on hourly basis!");
        }
    }

    public interface ISalariedEmployeeFactory
    {
        ISalariedEmployee Generate();
    }

    public interface IHourlyPaidEmployeeFactory
    {
        IHourlyPaidEmployee Generate();
    }

    public class SalariedEmployeeFactory : ISalariedEmployeeFactory
    {
        public ISalariedEmployee Generate()
        {
            Console.WriteLine($"This can be used to create salaried employee!");
            return new SalariedEmployee();
        }
    }

    public class HourlyPaidEmployeeFactory : IHourlyPaidEmployeeFactory
    {
        public IHourlyPaidEmployee Generate()
        {
            Console.WriteLine($"This can be used to create hourly paid employee!");
            return new HourlyPaidEmployee();
        }
    }

    public class AbstractFactoryMain
    {
        public static void Main(string[] args)
        {
            var salariedEmployee = new SalariedEmployeeFactory().Generate();
            salariedEmployee.Create("Satish");

            Console.WriteLine();

            var contractBasisEmployee = new HourlyPaidEmployeeFactory().Generate();
            contractBasisEmployee.Create("Dhavan");
        }
    }
}

That is all the information we have about "Abstract Factory" for now. In subsequent blogs, we will see a lot more patterns that fall into different gamma categories. Follow along and,

Happy Coding…!!!

Factory Pattern

Pranil Tunga — Tue, 16 May 2023 18:57:10 +0000

What is Factory:

A factory is a piece of code or a block of code that allows us to create entire objects at once.

Motivation:

In some cases, it is not a good idea to create objects using constructors because they are bound to the classes and their names must match the class names, which makes them less descriptive and prevents us from really describing more by using them. Additionally, passing multiple parameters can be confusing, and if we need to expand the constructor in the future, we might have to add optional parameters, which can unintentionally cause errors.

Instead of using constructors, we can use a complete separate code block and the "Factory Design Pattern" to create objects as conveniently as possible.

Why do we require it?

In order to understand why we need a factory, let's talk about some issues with constructors using an example.

public class Coordinates
{
    public double x { get; set; }
    public double y { get; set; }

    public Coordinates(double x, double y)
    {
        this.x = x;
        this.y = y;
    }
}

We have a class that accepts "coordinates," which in this case is acceptable. However, if we decide to accept "longitude" and "latitude" as well in the future, that will prevent us from doing certain things. Let's look at an example.

public class Coordinates
{
    public double x { get; set; }
    public double y { get; set; }

    public Coordinates(decimal x, decimal y)
    {
        this.x = x;
        this.y = y;
    }

    public double lan { get; set; }
    public double lat { get; set; }

    public Coordinates(double lan, double lat)
    {
        this.lan = lan;
        this.lat = lat;
    }
}

This is a problem because there is no way to allow our class to accept longitude and latitude. As we can see, C# does not allow a second constructor definition because we cannot overload constructors with the same parameter definitions.

Does this problem have a solution?

Yes, and the straightforward response is "factory." We can use the same class to make some factory methods available for creating new objects; let's take a look at how we can do that.

public class Coordinates
{
    public double x { get; set; }
    public double y { get; set; }

    private Coordinates(double x, double y)
    {
        this.x = x;
        this.y = y;
    }

    public static Coordinates CreateNormalCoordinates(double x, double y)
    {
        return new Coordinates(x, y);
    }
}

As you can see, I changed our constructor to be private, and we are now exposing a static method to create an object of Normal Co-ordinates. Adding new meanings to that class is now much simpler; all we need to do is add a new method to initialize the co-ordinates, and that will allow us to make them accept longitude and latitude as well. Let's add that method, and the finished code will resemble this:

namespace DesignPatterns
{
    public class Coordinates
    {
        public double x { get; set; }
        public double y { get; set; }

        private Coordinates(double x, double y)
        {
            this.x = x;
            this.y = y;
        }

        public static Coordinates CreateNormalCoordinates(double x, double y)
        {
            return new Coordinates(x, y);
        }

        public static Coordinates CreateGeoCoordinates(double longitude, double latitude)
        {
            return new Coordinates(longitude, latitude);
        }

        public override string ToString()
        {
            return $"{x}:{y}";
        }
    }

    public class FactoryPattern
    {
        public static void Main(string[] args)
        {
            var normal = Coordinates.CreateNormalCoordinates(10, 20);
            var geo = Coordinates.CreateGeoCoordinates(90.20, 20.80);

            Console.WriteLine(normal);
            Console.WriteLine(geo);
        }
    }
}

Therefore, the code above is much clearer now, and we are providing better APIs for users to create complete objects, which allows us to be more precise when calling those methods because there is no longer a need to overwhelm users with numerous constructor declarations.

Async Factory:

You might be wondering: We know what a factory is, but what exactly is an async factory? And it is nothing more than the asynchronous implementation of a factory. When async code is required, such as when threads are given priority and async object creation is required to support multithreading more precisely, it is important to take this into consideration.

Before we discuss why we require this kind of factory, let's take a look at an example of an async factory.

public async Coordinates(double x, double y)
{
    this.x = x;
    this.y = y;
}

As a result of this limitation, we must declare an Async block of code that can create an object for us. Let's take a look at how to do that in C# since there is no way to mark the constructor as "async".

public class Coordinates
{
    public double x { get; set; }
    public double y { get; set; }

    public Coordinates(double x, double y)
    {
        this.x = x;
        this.y = y;
    }

    public static async Task<Coordinates> InitWithCurrentCoordinates()
    {
        //Here I am adding dummy delay, you can call 3rd party api to get 
        //User current longitude & latitude based on public IP lookup
        await Task.Delay(1000);
        return new Coordinates(10, 20);
    }

    public override string ToString()
    {
        return $"{x}:{y}";
    }
}

public class FactoryPattern
{
    public static void Main(string[] args)
    {
        var currrent = Coordinates.InitWithCurrentCoordinates();
        Console.WriteLine(currrent);
    }
}

Let's say we need to get users' coordinates based on a reverse IP lookup and for that we need to call a third-party API. In that case, you can't just use the constructor because API calls might take several seconds to return data, and blocking the entire thread for those many seconds is not a good idea. Therefore, as you can see in the above code, we are creating a new method called "InitWithCurrentCoordinates" which is "async” in nature and can take care of both asynchronous behavior and object creation in one go.

That concludes this blog post. In our upcoming blogs, we will discuss the various factories that can be implemented, just as we did for builder patterns in our previous blogs.

Happy Coding…!!!

Façade on “Builder”

Pranil Tunga — Tue, 16 May 2023 18:52:08 +0000

As promised, in this blog we will examine the façade pattern for the builders and how we can use it to make our object creation beautiful. In our previous blog, we learned about the functional approach when creating the builder.

You can probably guess what we are about to create just by looking at the name, but let me explain a little more. In this pattern, we basically try to provide a façade around the functionality, which means that we divide our builders and try to provide separate wrappers (façade) around them to create whole objects with proper segregation.

Let's use an example to better understand this. Assume for the moment that we are working with a view model similar to the one shown in the example below.

{
    "RollNumber":"1",
    "Name":"Virat Kohli",
    "GraduationDetails": {
        "College":"Delhi university",
        "Percentage":"90%"
    },
    "PostGraduationDetails": {
        "College":"Gujrat university",
        "Percentage":"85%"
    }
}

So, this is how our C# model will appear:

public class Details
{
    public string College { get; set; }
    public double Percentage { get; set; }
}

public class Student
{
    public string RollNumber { get; set; }
    public string Name { get; set; }
    public Details GraduationDetails = new Details();
    public Details PostGraduationDetails = new Details();
}

Let's now create a builder to create objects for the Student class; this builder will resemble the following:

public class StudentBuilder
{
    private Student _student = new Student();

    public StudentBuilder WithRollNumber(string rollNumber)
    {
        _student.RollNumber = rollNumber;
        return this;
    }

    public StudentBuilder WithName(string name)
    {
        _student.Name = name;
        return this;
    }

    public StudentBuilder HadGraduationFrom(string college, decimal percentage)
    {
        _student.GraduationDetails.College = college;
        _student.GraduationDetails.Percentage = percentage;
        return this;
    }

    public StudentBuilder HadPostGraduationFrom(string college, decimal percentage)
    {
        _student.PostGraduationDetails.College = college;
        _student.PostGraduationDetails.Percentage = percentage;
        return this;
    }
}

Now, in this scenario, we have a builder to create an object of the Student class, and we have exposed multiple methods to accept details, but this is making our builder so big that there may be a chance that a user can mess up because there is no such logical boundary defined and all functionalities are tied to one class, which can lead to messy code later on, and this is kind of breaking the "Single Responsibility Principle" because we have to modify the builder for multiple reasons.

You might be wondering how façades play a role in this. The simple solution is to divide our Student class into three logical boundaries, with the properties "Name" and "RollNumber" falling under the student's personal details, the student's graduation details, and the student's post graduation details, respectively. If we somehow provide three façades and later bind them to a single builder, then we can very easily separate our code and also achieve the “Single Responsibility Principle”.

Let's construct new facades.

public class StudentBuilder
{
    protected Student student = new Student();

    public StudentPersonalInfoBuilder Personal => new StudentPersonalInfoBuilder(student);
    public StudentGraduationInfoBuilder Graduation => new StudentGraduationInfoBuilder(student);
    public StudentPostGraduationInfoBuilder PostGraduation => new StudentPostGraduationInfoBuilder(student);

    public static implicit operator Student(StudentBuilder builder)
    {
        return builder.student;
    }
}

public class StudentPersonalInfoBuilder : StudentBuilder
{
    public StudentPersonalInfoBuilder(Student student) { this.student = student; }

    public StudentPersonalInfoBuilder WithRollNumber(string rollNumber)
    {
        this.student.RollNumber = rollNumber;
        return this;
    }

    public StudentPersonalInfoBuilder WithName(string name)
    {
        this.student.Name = name;
        return this;
    }
}

public class StudentGraduationInfoBuilder : StudentBuilder
{
    public StudentGraduationInfoBuilder(Student student) { this.student = student; }

    public StudentGraduationInfoBuilder HadGraduationFrom(string college, double percentage)
    {
        this.student.GraduationDetails.College = college;
        this.student.GraduationDetails.Percentage = percentage;
        return this;
    }
}

public class StudentPostGraduationInfoBuilder : StudentBuilder
{
    public StudentPostGraduationInfoBuilder(Student student) { this.student = student; }

    public StudentPostGraduationInfoBuilder HadPostGraduationFrom(string college, double percentage)
    {
        this.student.PostGraduationDetails.College = college;
        this.student.PostGraduationDetails.Percentage = percentage;
        return this;
    }
}

As we just discussed, we have now created three new builders. The "StudentPersonalInfoBuilder" is in charge of initializing the student's personal information, and we are using other builders to initialize the student's graduation information and post-graduation information, respectively.

Final code will look something like this:

namespace Builder.FacadeBuilder
{
    public class Details
    {
        public string College { get; set; }
        public double Percentage { get; set; }
    }

    public class Student
    {
        public string RollNumber { get; set; }
        public string Name { get; set; }

        public Details GraduationDetails = new Details();

        public Details PostGraduationDetails = new Details();
    }

    public class StudentBuilder
    {
        protected Student student = new Student();

        public StudentPersonalInfoBuilder Personal => new StudentPersonalInfoBuilder(student);
        public StudentGraduationInfoBuilder Graduation => new StudentGraduationInfoBuilder(student);
        public StudentPostGraduationInfoBuilder PostGraduation => new StudentPostGraduationInfoBuilder(student);

        public static implicit operator Student(StudentBuilder builder)
        {
            return builder.student;
        }
    }

    public class StudentPersonalInfoBuilder : StudentBuilder
    {
        public StudentPersonalInfoBuilder(Student student) { this.student = student; }

        public StudentPersonalInfoBuilder WithRollNumber(string rollNumber)
        {
            this.student.RollNumber = rollNumber;
            return this;
        }

        public StudentPersonalInfoBuilder WithName(string name)
        {
            this.student.Name = name;
            return this;
        }
    }

    public class StudentGraduationInfoBuilder : StudentBuilder
    {
        public StudentGraduationInfoBuilder(Student student) { this.student = student; }

        public StudentGraduationInfoBuilder HadGraduationFrom(string college, double percentage)
        {
            this.student.GraduationDetails.College = college;
            this.student.GraduationDetails.Percentage = percentage;
            return this;
        }
    }

    public class StudentPostGraduationInfoBuilder : StudentBuilder
    {
        public StudentPostGraduationInfoBuilder(Student student) { this.student = student; }

        public StudentPostGraduationInfoBuilder HadPostGraduationFrom(string college, double percentage)
        {
            this.student.PostGraduationDetails.College = college;
            this.student.PostGraduationDetails.Percentage = percentage;
            return this;
        }
    }

    public class FacadeBuilderMain
    {
        public static void Main(string[] args)
        {
            Student student = new StudentBuilder()
                        .Personal.WithRollNumber("ST001")
                                 .WithName("Virat Kohli")
                        .Graduation.HadGraduationFrom("Delhi University", 90.4)
                        .PostGraduation.HadPostGraduationFrom("Punjab University", 87.57);

            Console.WriteLine(@$"
                Roll Number : {student.RollNumber}  
                Name : {student.Name}
                Graduated from {student.GraduationDetails.College} with {student.GraduationDetails.Percentage}
                Post Graduated from  {student.PostGraduationDetails.College} with {student.PostGraduationDetails.Percentage}          
            ");
        }
    }
}

We are using a very unusual method to extract the actual object, and that is by using "implicit" operator overriding, where all of these façades are converted to the "Student" class implicitly. Another thing you might notice is that we are also able to maintain fluency, and that is because we are inheriting the StudentBuilder class in each of our builders.

It is difficult to create a faceted builder with structural types when there is no reference available, but fear not, we can do that by using functions and we can use the "pass by reference" mechanism to get references of structural types, or if your company allows "unsafe" code, then you can simply use pointers to pass references of structural types to façades. However, since in this example we are using classes, and as we know, classes have their own set of references, we can pass them directly and share references to façades.

As we discussed in all blogs related to “Builder Pattern," we can use builders to decorate our object creation, and we can format our code to generate objects. Here comes the end of our blog, and this is also the end of Builder Patterns. In coming blogs, we will discuss more “creational” patterns.

Happy Coding…!!!

Functional “Builder”

Pranil Tunga — Tue, 16 May 2023 18:48:07 +0000

In our previous blog, we examined the Stepwise builder, where following steps is a requirement for the pattern and we attempt to drive object creation by following some steps one at a time. In this blog, we will examine the Functional builder, another variant where we avoid class extension through inheritance and try to functionally extend the existing builder class either by using more functional ways like extensions or functional paradigms.

Reusing the existing Employee Class will enable us to create a builder that gives users the ability to create the class's objects.

public class Employee
{
    public Guid Id { get; set; }
    public decimal Salary { get; set; }
}

Let's create a functional builder right away to generate an employee id, and then we'll talk about how we did it in more detail.

public sealed class EmployeeBuilder
{
    public readonly List<Func<Employee, Employee>> actions = new List<Func<Employee, Employee>>();

    public EmployeeBuilder GenerateEmployeeId()
    {
        Perform(e => e.Id = Guid.NewGuid());
        return this;
    }

    public Employee Build()
    {
        return actions.Aggregate(new Employee(), (e, func) => func(e));
    }

    public EmployeeBuilder Perform(Action<Employee> action)
    {
       actions.Add(e =>
       {
           action(e);
           return e;
       });
       return this;
    }
}

Now, in order to allow users to pass Lambda functions to modify Employee object values, we are using List>. We can chain multiple methods on the Employee object in a single action if we follow fluency, which is ensured by the second parameter.

By declaring the Perform method, we are giving the user an API so they can add actions to our read-only list of actions (used to store all actions so we can execute them one at a time on the same object passed). However, since this method is public, we can actually use it later to perform more actions. For example, in the "GenerateEmployeeId()" method, we use the "Perform()" method to create an employee's unique ID.

Let's reuse our builder now, adhering to the Open-Close principle so that we don't have to modify it but rather extend it to prevent inheritance. I purposefully added the "sealed" keyword to the class to mimic the requirement where we are not allowed to extend classes in order to prevent anyone from inheriting the class and to implement a functional way to extend our Builder. Let's look at how we can extend that with the help of an example.

public static class EmployeeBuilderExtensions
{
    public static EmployeeBuilder WithSalary(this EmployeeBuilder builder, decimal salary)
    {
        builder.Perform(b => b.Salary = salary);
        return builder;
    }
}

Consider how easy it is to add new functionality to an existing builder. We can also perform different actions while creating the objects, and we can construct the final object by aggregating all the specified actions on the same object.

Therefore, if we need to extend an existing builder class but are unable to inherit from it because of some business requirements, we can still benefit from the open-closed principle by using this functional approach.

You'll notice that EmployeeBuilder contains redundant code, and if we later need to create a Builder for another class, we'll have to repeat the same code, which is bad because we should extract the same code and avoid redundancy. In this case, we can use generics to extract the code for multiple types (i.e., for multiple classes), so let's take a look at how we can do that.

public abstract class FunctionalBuilder<TBuilder, TCurrent>
        where TCurrent : FunctionalBuilder<TBuilder, TCurrent>
        where TBuilder : new()
{
    public readonly List<Func<TBuilder, TBuilder>> actions = new List<Func<TBuilder, TBuilder>>();

    public TBuilder Build()
    {
        return actions.Aggregate(new TBuilder(), (b, func) => func(b));
    }

    public TCurrent Perform(Action<TBuilder> action)
    {
        actions.Add(e =>
        {
            action(e);
            return e;
        });
        return (TCurrent)this;
    }
}

After putting the functionality into a generic class, we can now create actual builders from this by deriving from the abstract "FunctionalBuilder" class, where “TBuilder” is the type for which we want to create a Builder and “TCurrent” is the instance of a Builder we are creating. By returning the same builder type, this will enable us to achieve fluency. For instance, if we create an "EmployeeBuilder," all methods from "FunctionalBuilder" will return "EmployeeBuilder," enabling fluency.

Let's try to implement a builder for our Employee class using this generic class, where we should be able to create employee objects with EmployeeId and Salary.

public class EmployeeBuilder : FunctionalBuilder<Employee, EmployeeBuilder>
{
    public EmployeeBuilder GenerateEmployeeId()
    {
        Perform(e => e.Id = Guid.NewGuid());
        return this;
    }

    public EmployeeBuilder WithSalary(decimal salary)
    {
        Perform(e => e.Salary = salary);
        return this;
    }
}

And in our primary method, we can apply this as follows:

public class FunctionalBuilderMain
{
    public static void Main(string[] args)
    {
        var employee = new EmployeeBuilder()
                           .GenerateEmployeeId()
                           .WithSalary(2000)
                           .Build();

        Console.WriteLine($"Employee created with Id: {employee.Id} and Salary : ${employee.Salary}");
    }
}

After combining the above code snippets, we'll get something like this, which we can start using to create/extend further by introducing new Builders.

namespace Builder.FunctionalBuilder
{
    public class Employee
    {
        public Guid Id { get; set; }
        public decimal Salary { get; set; }
    }

    public abstract class FunctionalBuilder<TBuilder, TCurrent>
        where TCurrent : FunctionalBuilder<TBuilder, TCurrent>
        where TBuilder : new()
    {
        public readonly List<Func<TBuilder, TBuilder>> actions = new List<Func<TBuilder, TBuilder>>();

        public TBuilder Build()
        {
            return actions.Aggregate(new TBuilder(), (b, func) => func(b));
        }

        public TCurrent Perform(Action<TBuilder> action)
        {
            actions.Add(e =>
            {
                action(e);
                return e;
            });
            return (TCurrent)this;
        }
    }

    public class EmployeeBuilder : FunctionalBuilder<Employee, EmployeeBuilder>
    {
        public EmployeeBuilder GenerateEmployeeId()
        {
            Perform(e => e.Id = Guid.NewGuid());
            return this;
        }

        public EmployeeBuilder WithSalary(decimal salary)
        {
            Perform(e => e.Salary = salary);
            return this;
        }
    }

    public class FunctionalBuilderMain
    {
        public static void Main(string[] args)
        {
            var employee = new EmployeeBuilder()
                               .GenerateEmployeeId()
                               .WithSalary(2000)
                               .Build();

            Console.WriteLine($"Employee created with Id: {employee.Id} and Salary : ${employee.Salary}");
        }
    }
}

Finally, I just wanted to encourage people to start using functional builders when they want to extend their builders but can't use inheritance. In our next blog, we'll look at how we can add extra abstraction over the builders by introducing some masking patterns.

Happy Coding..!!!

Stepwise “Builder”

Pranil Tunga — Tue, 16 May 2023 18:40:29 +0000

In our previous blog, we discussed the necessity of builder inheritance fluency as well as the benefits of occasionally extending an existing builder while still adhering to the SOLID principles (i.e., by using the Open-Closed principle). Here, we'll talk about a very unique situation involving builders that may come in handy when stepwise object creation is required.

Let's look at an example: in our previous blog, we created the Employee class, but now the requirements have changed and we must set salary based on the designation, so take a look at our new "Employee" class.

public enum Designations
{
    Employee,
    Manager,
    TechnicalLead
}

public class Employee
{
    public Guid Id { get; set; }
    public Designations Designation { get; set; }
    public decimal Salary { get; set; }
}

public class EmployeeBuilder
{
    private Employee _employee = new Employee();

    public EmployeeBuilder Create(Designations desg, decimal salary)
    {
        _employee = new Employee
        {
            Id = Guid.NewGuid(),
            Designation = desg,
            Salary = salary
        };

        return this;
    }

    public Employee Build()
    {
        return _employee;
    }
}

The example above will satisfy our basic needs for object creation, but there is a very significant flaw in the code. Currently, we are exposing the "Create()" method to the user, and while we accept both the employee's designation and salary, what happens if the user enters the incorrect designation and salary? Since the user must worry about the business logic, this solution does not appear to be ideal. Another thing is that we shouldn't let users set salaries; instead, it should be set to a property according to our business logic. You might wonder what should be done to fix this, and the answer is very straightforward: we can use "Stepwise Builder" to close any loophole that is currently present.

namespace Builder.StepwiseBuilder
{
    public enum Designations
    {
        Employee,
        Manager,
        TechnicalLead
    }

    public interface IDesignationBuilder
    {
        ISalaryBuilder WithDesignation(Designations designation);
    }

    public interface ISalaryBuilder
    {
        IEmployeeBuilder AssignSalary();
    }

    public interface IEmployeeBuilder
    {
        Employee Build();
    }

    public class Employee
    {
        public Guid Id { get; set; }
        public Designations Designation { get; set; }
        public decimal Salary { get; set; }

        public static Builder CreateBuilder()
        {
            return new Builder();
        }

        public class Builder : IDesignationBuilder, ISalaryBuilder, IEmployeeBuilder
        {
            private Employee _employee = new Employee();

            public ISalaryBuilder WithDesignation(Designations designation)
            {
                _employee.Designation = designation;
                return this;
            }

            public IEmployeeBuilder AssignSalary()
            {
                switch (_employee.Designation)
                {
                    case Designations.Employee:
                        _employee.Salary = 1000;
                        break;
                    case Designations.Manager:
                        _employee.Salary = 5000;
                        break;
                    case Designations.TechnicalLead:
                        _employee.Salary = 10000;
                        break;
                    default:
                        throw new InvalidOperationException("Designation not supported, please pass valid designation");
                }

                return this;
            }

            public Employee Build()
            {
                return _employee;
            }
        }
    }

    public class StepWiseBuilderExample
    {
        public static void Main(string[] args)
        {
            var employee = Employee.CreateBuilder()
                                   .WithDesignation(Designations.Employee)
                                   .AssignSalary()
                                   .Build();

            Console.WriteLine($"{employee.Designation} gets paid ${employee.Salary}");
        }
    }
}

Here, we are using different interfaces for different purposes and later creating a chain so that we can perform operations in specific steps. As you can see, "IDesignationBuilder" is returning "ISalaryBuilder" and so on, so that we can only perform salary-related operations after designation is set. In this way, we are inadvertently forcing users to follow steps and also making sure that Business logic is followed.

Finally, I just wanted to emphasize how important this type of Builder is and how it can be used in many different contexts, especially when performing domain-based programming, where you need to make sure that objects are created with purpose and that users follow the proper procedures to create objects.

So that's it for this blog post. In our following blog, we'll look at more ways to implement builders and talk about some of their applications. Until then.

Happy Coding…!!!

Fluency in “Builder Inheritance”

Pranil Tunga — Tue, 16 May 2023 18:37:20 +0000

As we concluded in our previous blog, there are some crucial issues that we still need to consider, so let's talk about them in this one. In our previous blog, we learned about the fundamentals of the builder pattern and why it is necessary to refactor our code to expose a better interface.

Fluency in Builder Inheritance:

You may be wondering what fluency is. And why does it matter? Please allow me to clarify that: fluent interface is not a term specifically associated with the Builder Pattern; in this, we attempt to return the same class object in every method so that the user may chain the various methods on the same class. Let's understand this with the aid of an example.

var sb = new StringBuilder();
sb.AppendLine("This is an example of fluent interface ")
  .Append("where we can chain multiple methods on same object ")
  .Append("cause all methods from StringBuilder class return same class object");

You can see that the code above is the ideal illustration of fluency because almost all methods return “this”, which refers to the current instance, so the user doesn't need to worry about the object and can chain methods without even thinking about it.

As we are all aware, the Builder pattern is a creational pattern that typically focuses on object creation. It shapes classes in such a way that users can easily create complex objects, but as we create classes, we also need to be mindful of the class properties like Inheritance, etc.

It is very common to inherit from pre-existing builders, but if we are using a fluent interface, we must be mindful of one particular aspect that we will comprehend through the use of a problem.

public class Employee
{
    public Guid EmployeeId { get; set; }
    public decimal Salary { get; set; }
}

public class EmployeeIdBuilder
{
    protected Employee Employee = new Employee();

    public EmployeeIdBuilder GenerateNewId()
    {
        Employee.EmployeeId = Guid.NewGuid();
        return this;
    }
}

As you can see, we have a builder called "EmployeeIdBuilder" that is responsible for creating a unique identifier for each employee. Now, let's say we need to create another builder for setting Employee Salary because we chose to use the Open-Closed principle and we decided not to touch the existing builder instead of extending it. Let's create that and try to build a new employee object.

public class EmployeeSalaryBuilder : EmployeeIdBuilder
{
    public EmployeeSalaryBuilder AddEmployeeSalary(decimal Salary)
    {
        Employee.Salary = Salary;
        return this;
    }
}

Let's use this class to create a new employee object since it was created from an existing Builder.

var employeeBuilder = new EmployeeIdBuilder()
                          .GenerateNewId()
                          .AddEmployeeSalary(2000);

The issue arises because we are using a fluent interface, which should allow the "AddEmployeeSalary()" method to chain on the already-existing method "GenerateNewId()" but does not. You might be wondering why this is the case. Because "EmployeeSalaryBuilder" is an inheriting class of "EmployeeIdBuilder," if you look closely, the "GenerateNewId()" method returns "EmployeeIdBuilder" while the "AddEmployeeSalary()" method returns "EmployeeSalaryBuilder," and once we call the first method, it prevents us from calling methods from “EmployeeSalaryBuilder.”.

You may now be wondering how we can resolve this, and the straightforward solution is generics. We can use recursive generics to inform base class about the existence of child class, which will resolve our problem because base class will learn about the existence of child classes and that can handle fluency.

public abstract class EmployeeBuider
    {
        protected Employee Employee = new Employee();

        public Employee Create()
        {
            return Employee;
        }
    }

    public class EmployeeIdBuilder<CURRENT>
        : EmployeeBuider
        where CURRENT : EmployeeIdBuilder<CURRENT>
    {
        public CURRENT GenerateNewId()
        {
            Employee.EmployeeId = Guid.NewGuid();
            return (CURRENT)this;
        }
    }

    public class EmployeeSalaryBuilderCURRENT>
        : EmployeeIdBuilder<EmployeeSalaryBuilder<CURRENT>>
        where CURRENT : EmployeeSalaryBuilder<CURRENT>
    {
        public CURRENT AddEmployeeSalary(decimal Salary)
        {
            Employee.Salary = Salary;
            return (CURRENT)this;
        }
    }

As you can see, the "EmployeeSalaryBuilder" class inherits from the "EmployeeIdBuilder" class while also passing its own class instance. As a result, the generic argument "CURRENT" from the "EmployeeIdBuilder" class will point to the "EmployeeSalaryBuilder" class, enabling us to call methods from extended interfaces, as well as all further extensions.

We now face the same issue as before: because we are using generics, we are unable to pass any class types to the EmployeeIdBuilder generic type, making it impossible to create an object of that builder or any other builder. Fortunately, we can easily fix this by introducing our own Builder from the Employee class, and the final code will look something like this:

namespace BuilderPattern.BuilderInheritanceWithFluentSupport
{

    public class Employee
    {
        public Guid EmployeeId { get; set; }
        public decimal Salary { get; set; }
        public class Builder : EmployeeSalaryBuilder<Builder> { }
        public static Builder CreateBuilder() { return new Builder(); }
    }

    public abstract class EmployeeBuider
    {
        protected Employee Employee = new Employee();

        public Employee Create()
        {
            return Employee;
        }
    }

    public class EmployeeIdBuilder<CURRENT>
        : EmployeeBuider
        where CURRENT : EmployeeIdBuilder<CURRENT>
    {
        public CURRENT GenerateNewId()
        {
            Employee.EmployeeId = Guid.NewGuid();
            return (CURRENT)this;
        }
    }

    public class EmployeeSalaryBuilderCURRENT>
        : EmployeeIdBuilder<EmployeeSalaryBuilder<CURRENT>>
        where CURRENT : EmployeeSalaryBuilder<CURRENT>
    {
        public CURRENT AddEmployeeSalary(decimal Salary)
        {
            Employee.Salary = Salary;
            return (CURRENT)this;
        }
    }

    public class Fluency
    {
        public static void Main(string[] args)
        {
            var employee = Employee. CreateBuilder()
                           .GenerateNewId()
                           .AddEmployeeSalary(2000)
                           .Create();

            Console.WriteLine($"Id: {employee.EmployeeId}, Salary: {employee.Salary}");
        }
    }
}

Now, this will successfully create an employee object using the Builder, which supports recursive generics, but one thing to note here is the most important part, let's take a close look at the newly created Builder of Employee class.

public class Employee
{
    public Guid EmployeeId { get; set; }
    public decimal Salary { get; set; }
    public class Builder : EmployeeSalaryBuilder<Builder> { }
    public static Builder CreateBuilder() { return new Builder(); }
}

The Builder class in the above code snippet is inheriting from the newly created builder rather than the one we already had, because the newly created builder will automatically notify the parent with a Builder class instance, and the parent will notify it's parent with its own type holding a Builder object.

The generic chain will look something like this

Builder will notify to

EmployeeSalaryBuilder<Builder> will notify to

EmployeeIdBuilder<EmployeeSalaryBuilder<Builder>>

And that’s what make chaining of methods possible.

So this was the brief about the fluency in Builder Inheritance and the problems we may face while inheriting from existing Builders, I would highly suggest looking into the recursive inheritance, if you are already using inheritance with Builders, cause at some point in time you will face the same issue and you should be prepared to solve that.

Also in our next blog we will see different types of Builders with respective examples, till then.

Happy Coding…!!!

“Builder Design Pattern”

Pranil Tunga — Tue, 16 May 2023 18:30:55 +0000

In our last blog, we learned about the gamma categorization, and it states that we have 3 major categories that are “Creational”, “Structural” and “Behavioral”, In this blog, we will discuss the first important pattern under the “Creational” category, i.e., “Builder Pattern."

Why Builder Pattern?

Sometimes, it is very easy to create an object; you just have to call a single constructor to achieve that, but sometimes you have to consider some special cases where you have to be very particular about object creation, otherwise it will lead to an error unknowingly. Let's use an example to better understand this. Let's say you want to create a paragraph using a long string, but you can't just use the string class constructor because that will be very difficult to maintain. Instead, you should try using the StringBuilder class, which enables us to create a string by adding shorter pieces to the one that already exists.

Additionally, having a large number of constructor parameters can be problematic because people may become confused or make mistakes when passing so many parameters to a single constructor. Instead, we should give users a way to create objects piece by piece, which is what the Builder pattern does. It offers users a better piece-by-piece approach or API so that they can create objects without any trouble.

Let’s look at an example, and let’s try to understand what problem the Builder Pattern solves for us.

using System.Text;

namespace DesignPatterns.BadBuilderPattern
{
    public class BuilderPattern
    {
        public static void Main(string[] args)
        {
            Dictionary<string, string> map = new Dictionary<string, string>
            {
               {"user","admin" }, {"email","admin@test.com" }
            };

            var sb = new StringBuilder();
            sb.AppendLine("{");
            foreach (var item in map)
            {
                sb.Append("\t{").AppendFormat("0:1"), item.Key, item.Value AppendLine("},");
            }
            sb.AppendLine("}");

            Console.WriteLine(sb);
        }
    }
}

As you can see, we are attempting to build a JSON object from the dictionary here, but we are already using C# code, which is fine for small use cases, but what if we later needed to construct large objects? In that scenario, we need some robust solution to build a JSON object, and we need some sort of “JsonBuilder” to remove the duplication in code and to provide an API with which we can build complex JSON objects.

namespace DesignPatterns.GoodBuilderPattern
{
    using System.Text;

    public class JsonRoot
    {
        private string _name = string.Empty;
        public List<JsonPair> Children = new List<JsonPair>();

        public JsonRoot(string Name)
        {
            _name = Name;
        }

        public string AsString()
        {
            var sb = new StringBuilder();
            sb.AppendLine("{");
            sb.AppendFormat("\t{0}: ", _name). AppendLine("{");

            foreach (var c in Children)
            {
                sb.Append("\t\t{");
                sb.AppendFormat(" {0} : {1} ", c.Key, c.Value).Append(" },"). AppendLine();
            }

            sb.AppendLine("\t}");
            sb.AppendLine("}");

            return sb.ToString();
        }
    }

    public class JsonPair
    {
        public string Key = string.Empty;
        public string Value = string.Empty;
    }

    public class JsonBuilder
    {
        private JsonRoot _root;
        private string _rootName;

        public JsonBuilder(string RootName)
        {
            _rootName = RootName;
            _root = new JsonRoot(RootName);
        }

        public JsonBuilder AddKeyValuePair(string Key, string Value)
        {
            _root.Children.Add(new JsonPair
            {
                Key = Key,
                Value = Value
            }
            );
            return this;
        }

        public JsonBuilder Clear()
        {
            _root = new JsonRoot(_rootName);
            return this;
        }

        public string PrintJson()
        {
            return _root.AsString();
        }
    }

    public class BuilderPattern
    {
        public static void Main(string[] args)
        {
            var jb = new JsonBuilder("entries");
            jb.AddKeyValuePair("user", "admin");
            jb.AddKeyValuePair("email", "admin@user.com");
            jb.AddKeyValuePair("hobbies", "['dancing', 'singing']");

            Console.WriteLine(jb.PrintJson());
        }
    }
}

As you can see, we now have a reliable "JsonBuilder" class that allows us to create any type of JSON object.

Are we done with “builders”?

Not really. There are several considerations we must make when implementing the builder pattern, some of which will be covered in upcoming blogs. Additionally, there are several ways to create builders, so we will also cover those as well, so stay tuned!

At the conclusion, I'll say that the Builder pattern is a crucial one because it enables us to expose meaningful APIs by enclosing existing functionality. It is also used in C# because, as we all know, the "StringBuilder" class in C# uses the Builder pattern to create strings without allocating memory each time, improving performance.

Happy Coding…!!!

“Gamma Categorization” in Design Patterns

Pranil Tunga — Tue, 16 May 2023 18:25:03 +0000

You may be wondering what gamma categorization is, so let me clarify that it is nothing more than the logical border formed around the various design patterns, or we can say that we basically divide the numerous design patterns into multiple categories, and that categorization is known as “Gamma Categorization.”

This category is named after the famous author “Erich Gamma, who was one of the authors of “Gang of Four."

So as per the book, various design patterns are generally categorized into 3 major types of categories, which are “Creational”, “Structural” and “Behavioral”, By looking at their names, one can easily tell their purpose without even having coding knowledge, and this simplicity made this categorization simple and more understandable. Due to its simple nature, this categorization gained popularity among the developers because people were able to understand the gist behind the workings of a pattern just by looking at its category name.

Let’s discuss these categories in detail so that we can also get to know about them and classify various patterns that we are going to discuss in coming blogs. This will help us to better understand the behavior of patterns and we can better utilize them in our code to make it more self-explanatory.

1. Creational

So as we know, the first category is "Creational,” and the design patterns that fall under this category are generally known as “Creational Design Patterns." The main goal of this design pattern is to focus on object creation. In modern languages like Java or C#, we have multiple ways to create or construct objects. Sometimes object creation is very simple, but sometimes it requires some efforts and simplifications; otherwise, there are high chances that a user might make an error unknowingly. We can create objects either explicitly, i.e., by using a typical constructor, or implicitly, i.e., using a dependency injection container, reflections, and many more, which create objects behind the scenes for us. And these patterns also determine if an object is created in one go (a whole object at a time) or if it is created by providing chunks or pieces (step-by-step creation).

2. Structural

Now after creational, we are going to see our second category, i.e., “Structural” and again the patterns that reside under this category are known as “Structural Design Patterns” and as the name suggests, we can easily predict that these patterns are used to shape our code or to form a fixed structure. This categorization is mainly focused on various concerns, which are very helpful in shaping the structure of the class. Structural design patterns are generally known for the structures formed by the patterns that mimic the underlying contracts, i.e., we can say that this pattern revolves around wrappers and concepts that help us shape the classes by providing some sort of structure that can mimic the underlying interface. By using structural patterns, one can achieve very good API design.

3. Behavioral

The third major category is “behavioral.”, Unlike the first two patterns, this does not follow any theme, and all patterns are different in their own way. We can say that they are unique by their individual implementations and can be used to solve particular problems with their unique approach.

At the end, I wanted to conclude that all these categories are useful in their own way, but it’s up to us how we can use them to make our code more understandable, and we should choose them wisely. One should first understand the requirements of the application, and then choose a pattern that is beneficial and can make his life easy. If we do so, then we can write better code that is self-explanatory, and new developers can also contribute faster to that code due to its minimal complexity.

Happy Coding…!!!