DEV Community: Patrick Schadler

Builder Design Pattern

Patrick Schadler — Thu, 27 Feb 2020 11:43:05 +0000

Builder Design Pattern

This post was originally published here.

In today’s episode of Software Design Patterns you will learn everything about the Builder Design Pattern. The Builder Pattern is also pretty common and widely used. Different from the already covered behavioral pattern Observer, the Builder Pattern is a creational design patterns like Singleton and Factory Method pattern.

All the examples, source code and unit tests are in this GitHub repository.

DonkeyKongJr / BuilderPattern

This Repository hosts how a Builder Design Pattern could be used.

What’s the purpose of the Builder Design Pattern?

The Gang-of-Four [1] reference book ("Design Patterns. Elements of Reusable Object-Oriented Software") describes the intent of the Builder Pattern as the following.

Separate the construction of a complex object from its representation so that the same construction process can create different representations.

Basically, you have a builder and a director. In my example on GitHub I use different types of houses. There is a builder for flat and hipped houses. Those builders are created and passed to the director. The director itself constructs the different houses. To retrieve the built house the actual builder has a method for this (GetHouse()). Via this you can use the concrete house implementation.

How does the Builder look like?

In the picture below you find the Unified Modeling Language (UML) diagram.

In the linked GitHub repository you will find interfaces for the IHouseBuilder and the IDirector. Many resources advise you to use abstract base classes for the director and the builder - which is totally fine. I simply like interfaces more, so I went this route. The IHousebuilder interface contains the definition for building the house and retrieving the build instance. The IDirector simply has a construct method. In this method all steps should be done to build a specific thing - in our case a given type of house. The House class stores the model of a house. To make it simple I minimized the house to four property with getter only. To set value, you have to use the constructor when creating a house.

public interface IHouseBuilder
{
    void BuildHouse();
    House GetHouse();
}

public interface IDirector
{
    void Construct();
}

public class House
{
    public string PaintingColor { get; }
    public string RoofType { get; }
    public int NumbersOfFloors { get; }
    public bool HasCellar { get; }

    public House(string paintingColor, string roofType, int numbersOfFloors, bool hasCellar)
    {
        PaintingColor = paintingColor;
        RoofType = roofType;
        NumbersOfFloors = numbersOfFloors;
        HasCellar = hasCellar;
    }
}

The concrete house builders sets the correspondending values when creating a new instance.

public class FlatRoofHouseBuilder : IHouseBuilder
{
    private House _house = default(House);

    public void BuildHouse()
    {
        _house = new House("white", "flat", 1, false);
    }

    public House GetHouse()
    {
        return _house;
    }
}

public class HippedRoofHouseBuilder : IHouseBuilder
{
    private House _house = default(House);

    public void BuildHouse()
    {
        _house = new House("gray", "hipped", 2, true);
    }

    public House GetHouse()
    {
        return _house;
    }
}

The construct method on the director initiates the build process for the given house builder.

public class HouseBuildDirector : IDirector
{
    private readonly IHouseBuilder _houseBuilder;

    public HouseBuildDirector(IHouseBuilder houseBuilder)
    {
        _houseBuilder = houseBuilder;
    }

    public void Construct()
    {
        _houseBuilder.BuildHouse();
    }
}

In the unit tests you see the whole process of how to use the builder pattern. In this case it seems pretty odd to use such a pattern, but imagine that the complete build/construct process takes many complex steps.

public class BuilderPatternTest
{
    [Fact]
    public void ShouldBuildFlatHouse()
    {
        var flatHouseBuilder = new FlatRoofHouseBuilder();
        var houseBuildDirector = new HouseBuildDirector(flatHouseBuilder);

        houseBuildDirector.Construct();

        var house = flatHouseBuilder.GetHouse();

        house.HasCellar.Should().BeFalse();
        house.PaintingColor.Should().Be("white");
        house.RoofType.Should().Be("flat");
        house.NumbersOfFloors.Should().Be(1);
    }

    [Fact]
    public void ShouldBuildHippedHouse()
    {
        var hippedRoofHouseBuilder = new HippedRoofHouseBuilder();
        var houseBuildDirector = new HouseBuildDirector(hippedRoofHouseBuilder);

        houseBuildDirector.Construct();

        var house = hippedRoofHouseBuilder.GetHouse();

        house.HasCellar.Should().BeTrue();
        house.PaintingColor.Should().Be("gray");
        house.RoofType.Should().Be("hipped");
        house.NumbersOfFloors.Should().Be(2);
    }
}

Appendix: There are many ways of describing the builder pattern. Often it's mistaken by a fluent library where you chain different methods and eventually build an object from it. Let me know in the comments below how you find the builder or how you learned it.

If you have any questions or comments feel free to leave them below.

That’s it. Happy coding as always :).

References

[1] –Design patterns, software engineering, object-oriented programming

Factory Method Design Pattern

Patrick Schadler — Thu, 30 Jan 2020 14:43:34 +0000

This post was originally published here.

Factory Method Design Pattern

In today's episode of Software Design Patterns you will learn everything about the Factory Method Design Pattern. The Factory Method is a creational pattern. That means that the pattern has something to do with object creation. There are different types of design patterns. The other types are structural and behavioral. Those types will have a dedicated blog post in the future. For reference - the last article covered the Singleton Design Pattern - which is also a creational pattern. All the examples, source code and unit tests are in this GitHub repository.

DonkeyKongJr / FactoryMethodPattern

This Repository hosts how a Factory Method Design Pattern could be used.

FactoryMethodPattern

This Repository hosts how a Factory Method Design Pattern could be used.

You find an up-to-date description in the related blog post here. (Yet to come)

For any changes or updates please file a Pull Request.

View on GitHub

What’s the purpose of the Factory Method Design Pattern?

The Factory Method is a very common pattern, but strongly misused. I have seen many examples where methods were named factory, but did something completely different. The quote below - taken from the Gang of Four - is very precise about the Factory Method. The Factory Method Design Pattern defines an interface for creating an object, but let sub classes decide which class to instantiate. Factory Method lets a class defer instantiating to sub classes. [1]

Don't fall into the trap and use it for everything. If you are not sure about when to use, you probably don't need it anyway.

How does the Factory Method looks like?

In the picture below you find the Unified Modeling Language (UML) diagram. As mentioned at the beginning you find all the code examples in a working project on GitHub.

public interface ICar
{
    string GetName();
    void Accelerate();
    void Break();
}

public class ElectricCar : ICar
{
    public int Speed { get; private set; }

    public string GetName()
    {
        return "Electric";
    }

    public void Accelerate()
    {
        Speed = Speed + 2;
    }

    public void Break()
    {
        if (Speed > 0)
        {
            Speed--;
        }
    }
}

public class PetrolCar : ICar
{
    public int Speed { get; private set; }

    public string GetName()
    {
        return "Petrol";
    }

    public void Accelerate()
    {
        Speed++;
    }

    public void Break()
    {
        if (Speed > 0)
        {
            Speed--;
        }
    }
}

In this example we have an interface ICar.cs, which provides basic car operations like accelerate and break. In addition to that we have an GetName() method, were the concrete implementation should return the actual name of the car.

public class CarFactory
{
    public ICar CreateCar(string type)
    {
        if (string.Equals(type, "Petrol", StringComparison.OrdinalIgnoreCase))
        {
            return new PetrolCar();
        }

        if (string.Equals(type, "Electric", StringComparison.OrdinalIgnoreCase))
        {
            return new ElectricCar();
        }

        throw new NotSupportedException($Car Type '{type}' is not supported);
    }
}

Our Factory, called CarFactory.cs, is responsible for creating instances of concrete cars. We provide a dedicated CreateCar(string type) method, where the desired type can be passed as an argument. The method maps the type to a concrete implementation. This can be done via multiple if clauses or a switch statement. Anyway, if there is no matching type we throw an NotSupportedException to make it clear that the factory does not support the desired type. To see the proper use of the CarFactory look into the test project.

public class CarFactoryTest
{
    [Theory]
    [InlineData("Electric")]
    [InlineData("electric")]
    [InlineData("eLeCtriC")]
    public void ShouldCreateElectricCarInstance(string type)
    {
        var carFactory = new CarFactory();
        var car = carFactory.CreateCar(type);

        car.Should().BeOfType<ElectricCar>();
        car.GetName().Should().Be("Electric");
    }

    [Theory]
    [InlineData("Petrol")]
    [InlineData("petrol")]
    [InlineData("pEtRoL")]
    public void ShouldCreatePetrolCarInstance(string type)
    {
        var carFactory = new CarFactory();
        var car = carFactory.CreateCar(type);

        car.Should().BeOfType<PetrolCar>();
        car.GetName().Should().Be("Petrol");
    }

    [Theory]
    [InlineData("hans")]
    [InlineData("car")]
    [InlineData("electricpetrol")]
    public void ShouldThrowNotSupportedExceptionWhenTypeIsInvalid(string type)
    {
        var carFactory = new CarFactory();
        Action getCar = () => carFactory.CreateCar(type);

        getCar.Should().ThrowExactly<NotSupportedException>();
    }
}

If you have any questions or comments feel free to leave them below. That’s it. Happy coding as always.

References[1] -Design patterns, software engineering, object-oriented programming

Creating A OpenAPI (Swagger) Documentation For RESTful Services

Patrick Schadler — Wed, 29 Jan 2020 12:17:11 +0000

This post was originally published here.

In this Blog post we discover creating a OpenAPI (Swagger) documentation for WebAPI (ASP.NET) and why you should do it too. If you have any questions on creating a RESTful Service with C# and Visual Studio just look at this tutorial here.

First - what is Swagger? Swagger lets you create a beautiful and rich documentation for your RESTful web services. The creators itself calls Swagger THE WORLD'S MOST POPULAR API TOOLING. Furthermore, you can provide an easy way to test your web service with the in-built functionality from swagger. And the best part of it? It's free. And what makes it even better?
You just have to add a nuget package to your WebApi project to automatically create an interactive documentation. The nuget package you want to use is called Swashbuckle. Double check if there is a new version - if so, you just can update the command to match the latest version number. By running the following command you add all needed files to your current project.

PM> Install-Package Swashbuckle -Version 5.6.0

After the successful install process you will find a new file within the App_Start folder called SwaggerConfig.

App_Start -> SwaggerConfig.cs

If you don't need anything special you don't really want to modify this file - just leave it as it is for the moment. To see how your Swagger documentation looks like just run the Application by pressing F5 or the green start button. Make sure that you have chosen a Browser to run with. After the build of your project succeeds the browser window with your Home Controller will open. To navigate to your Swagger Documentation just enter /swagger to your given URL. The URL should look like the following example.

If you use a dotnet core project you can add swagger via the application builder and configure it via the service collection.

public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
    app.UseSwagger();
    app.UseSwaggerUI(c =>
    {
        c.SwaggerEndpoint($"/swagger/v{ApiInfo.CurrentVersion}/swagger.json", $"{ApiInfo.Name} v1");
        c.DocExpansion(DocExpansion.None);
    });
}

public void ConfigureServices(IServiceCollection services)
{
    services.AddSwaggerGen(options =>
        {
            options.SwaggerDoc(ApiVersion, new Info
            {
                Title = $"{ApiInfo.Name} {ApiVersion}",
                Description = ApiInfo.Description,
                Version = ApiVersion,
                Contact = new Contact
                {
                    Name = ApiInfo.ContactName,
                    Email = ApiInfo.ContactEmail,
                    Url = ApiInfo.ContactUrl
                }
            });
            options.DescribeAllEnumsAsStrings();
            options.DescribeAllParametersInCamelCase();
            options.OperationFilter<FileUploadOperation>();
        });
}

http://localhost:49442/swagger

If you have entered the URL you should be navigated to the documentation and test page. It will look similar to the following screenshot of mine. Swagger Documentation Page[/caption] On this page you can easily open every single controller you have defined in your WebApi Project. Within every controller section you will find all the available HTTP Methods (for example get, put, post, delete etc.) which you can test and execute immediately by using the Try it out! Button from this swagger page. That's everything you need to do to add a stunning swagger documentation to your WebApi Project. Happy Swaggering.

C# Unit Tests with Mocks

Patrick Schadler — Wed, 22 Jan 2020 15:38:25 +0000

This post was originally published here.

C# Unit Tests with Mocks provide an easy way of reducing unwanted dependencies when writing unit tests. One of the best and shortest definition for mocking is mocking is creating objects that simulate the behavior of real objects. - StackOverflow.

Prologue

However, when talking about writing unit tests I would strongly advise to not change the implementation itself. Rather, think about how you can test it easily before start writing the implementation. The very best approach for unit-testing would be Test-Driven-Development (TDD) anyway, but I understand that many struggles with this methodology. Especially when starting with tests in general. Always Keep in mind that the S.O.L.I.D Framework helps you a lot when writing unit tests.

Moq Framework

Moq is an open-source framework which can be found on GitHub. When start using Moq make sure you always install the very latest version. Moq is usable with any test runner like vstest, xunit, nunit etc. When using Moq or any other mocking framework keep following restrictions in mind. You can not mock:

Static class/methods.
Extensions Methods.
Non-virtual methods (except there is an interface).

For this blog post, I have used my link-reader repository. This project is written with dotnet core 2.1.

However, you can easily use a newer version of dotnet core if you want. You can see that in this particular case it is necessary to nest multiple mocks within each other. You can configure that one mock mocks a method and return another mock object. To generate a mock you just have to create a new Mock object and set the type. As you see Moq uses generics very heavily.

var moq = new Mock<IWebRequest>();

When you look at the IWebRequest definition you'll see that the interface has a Create method that all classes have to implement. Therefore, we can easily mock this method in our case by using the Setup.

moq.Setup(_ => _.Create(It.IsAny<string>())).Returns(moqHttpWebRequest.Object);

When you want to mock a method with parameters you can work with the It.IsAny() option. In the example above all string values are allowed. Of course, you can strict this up and allow only specific values to work with. To work with mocks you have to use the mock.Object property. This property is the actual mock implementation of the source.

var webRequest = moq.Object.Create(test);

The line above returns the moqHttpWebRequest.Object, because that's the way we have set up the mock behavior.

Customizing Mock Behavior

Moq provides different ways to set up the mock - MockBehavior.Strict

Verification

When you are using the verification from a mock instance by calling moq.Verify() it does check if all set up methods are called. You can check all Moq Setups without any Verifiable declaration by using the moq.VerifyAll() method on the mocked object. Happy mocking and testing.

Singleton Design Pattern in c#

Patrick Schadler — Mon, 20 Jan 2020 14:40:37 +0000

Singleton Design Pattern

This post was originally published at my personal blog here.

With this post a brand-new series about Software Design Patterns starts. You will learn everything about the most used Design Patterns. The first is probably the most known. It is the Singleton Design Pattern. It is one of the twenty-three well-known - and industry standard - Gang of Four Design Pattern Collection.

All the examples, source code and unit tests are in this GitHub repository.

DonkeyKongJr / SingletonDesignPattern

This Repository hosts how a Singleton Design Pattern could be used.

SingletonDesignPattern

This Repository hosts how a Singleton Design Pattern could be used.

You find an up-to-date description in the related blog post here.

For any changes or updates please file a Pull Request.

View on GitHub

What's the purpose of the Singleton Design Pattern?

In software development we often instantiate a class many times. This could be problematic. As a result you have to deal with many instances of the very same class. This introduces complexity and increases memory usage of the application.

The Singleton Design Pattern solves this specific issue. It ensures that only one instance of this class exists. Beyond that it standardizes and eases the access to that instance. To access the instance, a Singleton provides per design a static GetInstance() method. To prevent any instantiating via the new keyword you have to hide the constructor.

How does the Singleton Design Pattern looks like?

In the picture below you find the Unified Modeling Language (UML) diagram.

Singleton UML Diagram

The very basic implementation doesn't care about thread-safety. It's called BasicSingleton within the GitHub Repository.

public class BasicSingleton
{
    public string Name => Singleton;
    private static BasicSingleton instance;

    private BasicSingleton(){ }

    public static BasicSingleton GetInstance()
    {
        if(instance == default(BasicSingleton)){
                instance = new BasicSingleton();
        }

        return instance;
    }
}

How about Thread-Safety?

This implementation could lead to problems when many threads calls the GetInstance() simultaneously. For example the second thread enters the if condition while the first isn't finished yet. Thus, a second instance will be created. This behavior violates the Singleton Design Pattern definition. The ThreadSafeSingleton prevents those race conditions with locking the access to a thread at a time. This guarantees that only one instance will ever be created. Keep in mind that every time we access the Singleton we perform a lock which uses a bit more resources.

public class ThreadSafeSingleton
{
    public string Name => Singleton;
    private static ThreadSafeSingleton instance;
    private static readonly object singletonlock = new object();  

    private ThreadSafeSingleton(){ }

    public static ThreadSafeSingleton GetInstance()
    {
        lock (singletonlock)  
        {  
            if(instance == default(ThreadSafeSingleton))
            {
                instance = new ThreadSafeSingleton();
            }

            return instance;
        }          
    }
}

That’s it. Happy coding as always :).