DEV Community: Khalid BOURZAYQ

SRP - Is the most misunderstood principle ?

Khalid BOURZAYQ — Tue, 15 Mar 2022 11:59:58 +0000

Definition

Defined by Robert C. Martin, it’s the first of the five design principles SOLID.

what he said may seem very simple to us

A class should have only one reason to change

However, implementing this simplicity can be complicated.

And because of the confusion around the word "reason", he also stated

This principle is about people

What he means by people is the people who use our system or in other words the actors.

Actors become the source of change for the family of features that serve them.

As their needs change, that specific family must also change to meet their needs.

Uncle bob gave a funny example in The Single Responsibility Principle The Clean Code Blog

Imagine you took your car to a mechanic in order to fix a broken electric window. He calls you the next day saying it’s all fixed. When you pick up your car, you find the window works fine; but the car won’t start. It’s not likely you will return to that mechanic because he’s clearly an idiot.

That’s how customers and managers feel when we break things they care about that they did not ask us to change.

SRP is probably not what do you think it is. If you think that "A class should do only one thing and do it well", this is not the correct explanation of the principle (it's partially correct) and in the same time it's the most commun.

Yeah, this is the common misunderstanding of the principle.

Uncle Bob provides a more clear explanation in his book
"Clean Architecture: A Craftsman's Guide to Software Structure and Design" to further explain its intention in this principle.

A module should be responsible to one, and only one, actor

So, let's go on and see how we can apply SRP in practice.

Code refactoring example

Taking the following example, we have a product class where we find a set of methods:

A method to save the product in a txt file
A method that generates a report file.
Two other methods to manage or validate the data according to the management rules before changing the value of the field.

public class Product
{
    public string Label { get; set; }
    public string Description { get; private set; }
    public double Price { get; private set; }

    private readonly StringBuilder _priceActions = new();

    public Product(string description, string label, double price)
    {
        Label = label;
        ChangeDescription(description);
        ChangePrice(price);
    }

    public void ChangePrice(double price)
    {
        if (price == 0)
        {
            Console.WriteLine("price can't be zero!");
            throw new ArgumentNullException(nameof(price));
        } if (price < Price)
            _priceActions.Append($"New price applied to the product : ' {Label} '" +
                                 $". \n Old price {Price} " +
                                 $"\n New Price is {price}");
        Price = price;
    }

    public void ChangeDescription(string desc)
    {
        if (string.IsNullOrWhiteSpace(desc))
        {
            Console.WriteLine("description can't be null");
            throw new ArgumentNullException(nameof(desc));
        }
        Description = desc;
    }

    public void Save()
    {
        var fs = new FileStream("products.txt", FileMode.Append, FileAccess.Write);
        var writer = new StreamWriter(fs);
        writer.WriteLine($"Label:{Label},Description:{Description},Price:{Price}");
        writer.Close();
        fs.Close();
    }

    public void GenerateReportFile()
    {
        var fs = new FileStream("report.txt", FileMode.Create, FileAccess.Write);
        var writer = new StreamWriter(fs);
        writer.WriteLine("****this is a report****");
        writer.WriteLine("product basic infos");
        writer.WriteLine("-----------------------------------");
        writer.WriteLine($"{Label} - {Price}");
        writer.WriteLine($"Description : {Description}");
        writer.WriteLine("-----------------------------------");
        writer.WriteLine("price actions");
        writer.WriteLine($"{_priceActions}");
        writer.Close();
        fs.Close();
    }
}

If we think of the actors involved in the use of the product object, who could they be?

We can easily from these methods identify the following actors and reasons:

An editor who manages the basic information of the product.
Top management people for product reporting reasons.
The persistence way or the storage system.

Doing this kind of analysis, we can easily identify that the methods that we must have outside of the product class are the following:

Reporting method and related code stuff.
Storage method.
Validation rules and related messages.

So, let's refactor our code to follow SRP.

Let's start with the storage.

In this step, we will extract the method save into a new class which will be only responsible for storage stuff.
So, the related code in this class will change only if the storage manner change.

public interface IProductRepository
{
    void Save(Product product);
}

public class ProductRepository : IProductRepository
{
    public void Save(Product product)
    {
        var fs = new FileStream("products.txt", FileMode.Append, FileAccess.Write);
        var writer = new StreamWriter(fs);
        writer.WriteLine($"Label:{product.Label},Description:{product.Description},Price:{product.Price}");
        writer.Close();
        fs.Close();
    }
}

We will continue our refactoring by extracting all validation rules and business validation messages into classes that will be the single entry point for every change in our business rules.

We will refactor the code in this way:

First, we will extract the validation rules into a class that will be responsible only for product validations.
Second, all the messages will be in a single class which will represents the single entry point for our business validation messages.
In the final step, we will add a custom exception class for throwing all product business exception if something went wrong.

public class ProductBusinessException : Exception
{
    public ProductBusinessException(string message) : base(message)
    {
    }
}

public static class BusinessExceptionMessages
{
    public const string PriceIsnullErrorMessage = "price can't be zero!";
    public const string DescriptionIsnullErrorMessage = "description can't be null";
}

public class ProductValidator
{
    public static void ValidatePrice(double price)
    {
        if (price == 0)
            throw new ProductBusinessException(BusinessExceptionMessages.PriceIsnullErrorMessage);
    }

    public static void ValidateDescription(string description)
    {
        if (string.IsNullOrWhiteSpace(description))
            throw new ProductBusinessException(BusinessExceptionMessages.DescriptionIsnullErrorMessage);
    }
}

In the final step, we will refactor all the code related to the reporting stuff.

So, we will extract the method GenerateReportFile into a new class.
and we will add a new method to our product class in order to expose all the price changes related to the product.

    //New method in our product class 
    public string GetPriceChanges()
    {
        return _priceActions.ToString();
    }

public interface IProductTextReporting
{
    void GenerateReportFile(Product product);
}

public class ProductTextReporting : IProductTextReporting
{
    public void GenerateReportFile(Product product)
    {
        var fs = new FileStream("report.txt", FileMode.Create, FileAccess.Write);
        var writer = new StreamWriter(fs);
        writer.WriteLine("****this is a report****");
        writer.WriteLine("product basic infos");
        writer.WriteLine("-----------------------------------");
        writer.WriteLine($"{product.Label} - {product.Price}");
        writer.WriteLine($"Description : {product.Description}");
        writer.WriteLine("-----------------------------------");
        writer.WriteLine("price actions");
        writer.WriteLine($"{product.GetPriceChanges()}");
        writer.Close();
        fs.Close();
    }
}

After the refactoring, our product class looks like the code below.

public class Product
{
    public string Label { get; set; }
    public string Description { get; private set; }
    public double Price { get; private set; }

    private readonly StringBuilder _priceActions = new();

    public Product(string description, string label, double price)
    {
        Label = label;
        ChangeDescription(description);
        ChangePrice(price);
    }

    public void ChangePrice(double price)
    {
        ProductValidator.ValidatePrice(price);
        if (price < Price)
            _priceActions.Append($"New price applied to the product : ' {Label} '" +
                                 $". \n Old price {Price} " +
                                 $"\n New Price is {price}");
        Price = price;
    }

    public void ChangeDescription(string desc)
    {
        ProductValidator.ValidateDescription(desc);
        Description = desc;
    }

    public string GetPriceChanges()
    {
        return _priceActions.ToString();
    }
}

There it is ! we have refactored our code in a way that each class will have only one reason to change.

Final Thoughts

To conclude, once you find that a class or module starts to change for different reasons, take the time and effort to refactor your code to follow SRP, but needless refactoring can bring us down to classes or modules that are difficult to understand.

A second advice, if you are working in a high coupled software, module or class, be careful when you are refactoring your code, take you time in order to uncouple it before, because any fast refactoring step can lead you to a disaster.

That's it !
Ask me, comment below, share it, rate it, whatever you want.
See you soon.

References

Source code : Link to github with the whole code from this article
The Clean Code Blog : The Single Responsibility Principle
Clean Architecture: A Craftsman's Guide to Software Structure and Design

Be cautious when implementing the Open Closed Principle

Khalid BOURZAYQ — Thu, 10 Feb 2022 21:29:01 +0000

Caution

Without a clear understanding of polymorphism and composition, OCP and the rest of the principles of SOLID won't make much sense.

Overview Of OCP

"Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification."

What does this mean?

It means that your code should be written in a way that leaves it flexible to adapt to changes (Open), without modifying the code already written (Closed).

A simple use case: Filtering Customers by criteria

We have a user story in our application backlog which demand to us to retrieve all the required information about our customers stored in the database, based on different criteria.
So, let’s start with that:

    public enum CustomerType
    {
        UnRanked,
        Silver,
        Glod,
        Platinium
    }

And we have the Customer domain class

    public class Customer
    {
        public string Name { get; set; }
        public string LastName { get; set; }
        public string Address { get; set; }
        public CustomerType Type { get; set; }
    }

Now, we need to implement our filtering functionality. For example, we want to filter by Customer types:

    public class CustomersFilter
    {
        public List<Customer> FilterByType(IEnumerable<Customer> customers, CustomerType type) =>
                customers.Where(m => m.Type == type).ToList();
    }

public List<Customer> GetSilverCustomers()
{
    var customers = new List<Customer>
    {
       new Customer { Name = "C1", Type = CustomerType.Silver},
       new Customer { Name = "C2", Type = CustomerType.Silver},
       new Customer { Name = "C3", Type = CustomerType.Glod}
    };
    CustomersFilter customersFilter = new CustomersFilter();
    var result = customersFilter.FilterByType(customers, CustomerType.Silver);

    return result;
}

The user story is ok, validated and the code goes on production. After a couple of days, we receive a new user story in which the product owner wants to have a filter by subscription as well in the application.

What should we do in this case?

It should be easy, right?
We are going to add a second filter method by subscription and it will work perfectly.

Let's add the subscription enum

    public enum SubscribtionType
    {
        Free,
        Basic,
        Pro,
        Enterprise
    }

And now, we can add our new method in the CustomerFilter class

public class CustomersFilter
{
    public List<Customer> FilterByType(IEnumerable<Customer> customers, CustomerType type) =>
            customers.Where(m => m.Type == type).ToList();

    public List<Customer> FilterByScreen(IEnumerable<Customer> customers, SubscribtionType subscribtion) =>
        customers.Where(m => m.Subscribtion == subscribtion).ToList();
}

By testing the code that we have just added, everything works as it should, on the other hand we have just violated the OCP principle here because we have modified in the class instead of extending it.

Another problem here is that once a new filter is going to be expressed as a need, another filter method must be added.

So, what should we do in such cases?

There are several possible solutions, so that our code respects the OCP principle.
Solution 1: Use inheritance or interface implementation.
In the code below we are using interface implementation.

public interface IFilter<T, E> where T : class where E : Enum
{
    List<T> Apply(IEnumerable<T> collection, E type);
}

public class FilterBySubscibtion : IFilter<Customer, SubscribtionType>
{
    public List<Customer> Apply(IEnumerable<Customer> collection, SubscribtionType type)
    {
        return collection.Where(m => m.Subscribtion == type).ToList();
    }
}

public class FilterByCustomerType : IFilter<Customer, CustomerType>
{
    public List<Customer> Apply(IEnumerable<Customer> collection, CustomerType type)
    {
        return collection.Where(m => m.Type == type).ToList();
    }
}

And our calls will be like:

private List<Customer> customers { get; set; } = new List<Customer>
{
    new Customer { Name = "C1", Type = CustomerType.Silver, Subscribtion = SubscribtionType.Free},
    new Customer { Name = "C2", Type = CustomerType.Silver , Subscribtion = SubscribtionType.Basic},
    new Customer { Name = "C3", Type = CustomerType.Glod, Subscribtion = SubscribtionType.Basic}
};
public List<Customer> FilterCustomers(CustomerType customerType)
{
    IFilter<Customer, CustomerType> customersFilter = new FilterByCustomerType();
    var result = customersFilter.Apply(customers, customerType);
    return result;
}

public List<Customer> FilterCustomers(SubscribtionType subscribtion)
{
    IFilter<Customer, SubscribtionType> customersFilter = new FilterBySubscibtion();
    var result = customersFilter.Apply(customers, subscribtion);
    return result;
}

public List<Customer> GetSilverCustomers() => FilterCustomers(CustomerType.Silver);

public List<Customer> GetCustomersWithFreeSubscibtion() => FilterCustomers(SubscribtionType.Free);

As you can see in the code, we have set up two different implementations per filter type (subscription and customer type).
We also have two methods that call these two filters but we have redundancy in the code.

To avoid this kind of redundance, we will try to make a second implementation based on the specification design pattern.

Solution 2: Use specification pattern

In computer programming, the specification pattern is a particular
software design pattern, whereby business rules can be recombined by
chaining the business rules together using boolean logic. The pattern
is frequently used in the context of domain-driven design.

Source: Wikipedia - Specification pattern

The specification design model allows us to check if an object meets certain requirements (usually functional)
So, with this design pattern, we can reuse specs and combine them when needed.

Let's create our specifications:

public interface ISpecification<T>
{
    bool IsSatisfied(T item);
}

public class CustomerTypeSpecification : ISpecification<Customer>
{
    private readonly CustomerType _type;
    public CustomerTypeSpecification(CustomerType type)
    {
        _type = type;
    }
    public bool IsSatisfied(Customer item) => item.Type == _type;
}

public class SubscribtionTypeSpecification : ISpecification<Customer>
{
    private readonly SubscribtionType _type;
    public SubscribtionTypeSpecification(SubscribtionType type)
    {
        _type = type;
    }
    public bool IsSatisfied(Customer item) => item.Subscribtion == _type;
}

With the ISpecification interface, we can determine whether or not our criteria are met, and then we can send it to the Apply method from the IFilter interface.

Now, time to update our existing code to use these specifications:

    public interface IFilter<T> where T : class
    {
        List<T> Apply(IEnumerable<T> collection, ISpecification<T> specification);
    }

    public class CustomersFilter : IFilter<Customer>
    {
        public List<Customer> Apply(IEnumerable<Customer> collection, ISpecification<Customer> specification)
        {
            return collection.Where(m => specification.IsSatisfied(m)).ToList();
        }
    }

After updating the filter class, let's go to our finale class that use it and make some updates.

public class FilterService
{
    private readonly IFilter<Customer> _filter;

    private List<Customer> customers { get; set; } = new List<Customer>
    {
        new Customer { Name = "C1", Type = CustomerType.Silver, Subscribtion = SubscribtionType.Free},
        new Customer { Name = "C2", Type = CustomerType.Silver , Subscribtion = SubscribtionType.Basic},
        new Customer { Name = "C3", Type = CustomerType.Glod, Subscribtion = SubscribtionType.Basic}
    };
    public FilterService(IFilter<Customer> customerFilter)
    {
        _filter = customerFilter;
    }
    public List<Customer> FilterCustomers(ISpecification<Customer> specification)
    {
        return _filter.Apply(customers, specification);
    }

    public List<Customer> GetSilverCustomers() => FilterCustomers(new CustomerTypeSpecification(CustomerType.Silver));

    public List<Customer> GetCustomersWithFreeSubscibtion() => FilterCustomers(new SubscribtionTypeSpecification(SubscribtionType.Free));
}

As we can see we don’t have any code redundancy in our FilterService class.

Conclusion

We have just seen how OCP can help us create clean and maintainable code. But we must be careful when implementing this principle.

As we saw in our example, this wasn’t an efficient way to use class inheritance. But we shouldn't be afraid to do so, it's completely normal, but we should at least make these changes as discrete as possible.

In other cases, we will be led to use composition over inheritance and use a design pattern such as Strategy to achieve our goal.

To conclude, the idea of this article is to keep OCP in mind during our development and write extensible code as much as possible, because this leads to a maintainable, scalable and testable code base however how the implementation used.

Some useful links:
https://ardalis.github.io/Specification/
https://deviq.com/principles/open-closed-principle

Extended Property Patterns in C# 10

Khalid BOURZAYQ — Wed, 02 Feb 2022 18:33:55 +0000

What does it mean?

Basically, in C# 8.0 Microsoft has introduced the new pattern: Property pattern.

A property pattern matches an expression when an expression result is not null and every nested pattern matches the corresponding property or field of the expression result.

In C# 10, you can reference nested properties or fields within a property pattern.

Example

The following code sample shows a C# Customer class , which contains some properties and a nested property named Address which is in itself an object.


    public class Customer
    {
        public string Name { get; set; }
        public string LastName { get; set; }
        public Address Address { get; set; }

    }
    public class Address
    {
        public string City { get; set; }
        public string ZipCode { get; set; }

    }

    public class DiscountCalculator
    {
        public double GetDiscount(Customer customer)
        {
            if (customer is { Address : { City: "NYC" } })
            {
                return 0.8;
            }
            else
            {
                return 0.9;
            }
        }
    }

As you can see in our GetDiscount method, the syntax for accessing the address nested property is verbose


 if (customer is { FullAddress : { City: "NYC" } })

In C# 10, it’s much more practical, you can reference nested properties or fields within a property pattern.


if (customer is { FullAddress.City: "NYC" })

That's it, for more details about the Extended property patterns
you can refer to the link below:
Extended property patterns

A Quick view of Cached Repository Pattern

Khalid BOURZAYQ — Mon, 31 Jan 2022 14:15:26 +0000

In this article, we will see how to use the Cached Repository pattern with asp.net core web api and entity framework core.

The idea

In this exemple we will create an aspnet core webapi that fetches a list of cutomers stored in the database and the result will be a Data transfert object (DTO) that contains the list of customers and the time taken to fetch the data.

The database will be initialized with 10000 record for testing.

You can find the full source code of this sample in the link below:
https://github.com/kbourzayq/CachedRepository

The Repository Class before Applying cache

The repository class looks like :

public class CustomerRepository : IReadOnlyRepository<Customer>
{
    private readonly AppDbContext _context;

    public CustomerRepository(AppDbContext context)
    {
        _context = context;
    }

    public Customer GetById(int id)
    {
        return _context.Cutomers.First(x => x.Id == id);
    }

    public List<Customer> List()
    {
        return _context.Cutomers.Take(1000).ToList();
    }
}

The Api Controller class :

[Route("api/[controller]")]
[ApiController]
public class CustomerController : ControllerBase
{
    private readonly IReadOnlyRepository<Customer> _repository;

    public CustomerController(IReadOnlyRepository<Customer> repository)
    {
        _repository = repository;
    }
    [HttpGet]
    public ActionResult<CustomerListDto> GetAll()
    {
        var timer = Stopwatch.StartNew();
        var customers = _repository.List();
        timer.Stop();
        CustomerListDto customerList = new CustomerListDto { 
            Customers = customers, 
            ElapsedTimeMilliseconds = timer.ElapsedMilliseconds
        };
        return Ok(customerList);
    }
}

Time to inject dependencies and lunch our app:


Builder.Services.AddScoped<IReadOnlyRepository<Customer>, CustomerRepository>();

As you can see the loading of 1000 records takes some time...

{
  "elapsedTimeMilliseconds": 1226,
  "customers": [
    {
      "name": "Customer 0",
      "lastName": "Customer Lastname 0",
      "address": "Address 0",
      "id": 1
    },
    {
      "name": "Customer 1",
      "lastName": "Customer Lastname 1",
      "address": "Address 1",
      "id": 2
    },
    {
      "name": "Customer 2",
      "lastName": "Customer Lastname 2",
      "address": "Address 2",
      "id": 3
    },
    ....

Let's apply cache

In this example, we want to add caching behavior without modifying the existing code.
In other words, we should add caching to the application without touching any code in the repository implementation shown above or the webapi that uses it.
See: Open closed principle.
To do that, we will use the Decorator pattern.
The Decorator pattern is used to add some behaviors to an existing type without affecting the behavior of other types.

The Cached Repository class looks like the code below :

public class CachedCustomerRepository : IReadOnlyRepository<Customer>
{
    private readonly CustomerRepository _repository;
    private readonly IMemoryCache _cache;
    private const string CustomersCacheKey = "Sample::Customers";
    private MemoryCacheEntryOptions cacheOptions;


    public CachedCustomerRepository(CustomerRepository repository,
        IMemoryCache cache)
    {
        _repository = repository;
        _cache = cache;
        cacheOptions = new MemoryCacheEntryOptions()
            .SetAbsoluteExpiration(relative: TimeSpan.FromSeconds(20));
    }

    public Customer GetById(int id)
    {
        string key = CustomersCacheKey + "-" + id;

        return _cache.GetOrCreate(key, entry =>
        {
            entry.SetOptions(cacheOptions);
            return _repository.GetById(id);
        });
    }

    public List<Customer> List()
    {
        return _cache.GetOrCreate(CustomersCacheKey, entry =>
        {
            entry.SetOptions(cacheOptions);
            return _repository.List();
        });
    }
}

The next setp is to change the injected dependencies :

Builder.Services.AddScoped<IReadOnlyRepository<Customer>, CachedCustomerRepository>();
Builder.Services.AddScoped<CustomerRepository>();
Builder.Services.AddSingleton<IMemoryCache, MemoryCache>();

Now, after implementing our cache, we will launch our application and see what it will give us

First call :

{
  "elapsedTimeMilliseconds": 1224,
  "customers": [
    {
      "name": "Customer 0",
      "lastName": "Customer Lastname 0",
      "address": "Address 0",
      "id": 1
    },
    {
      "name": "Customer 1",
      "lastName": "Customer Lastname 1",
      "address": "Address 1",
      "id": 2
    },
    {
      "name": "Customer 2",
      "lastName": "Customer Lastname 2",
      "address": "Address 2",
      "id": 3
    },
    ....

Second call :

{
  "elapsedTimeMilliseconds": 0,
  "customers": [
    {
      "name": "Customer 0",
      "lastName": "Customer Lastname 0",
      "address": "Address 0",
      "id": 1
    },
    {
      "name": "Customer 1",
      "lastName": "Customer Lastname 1",
      "address": "Address 1",
      "id": 2
    },
    {
      "name": "Customer 2",
      "lastName": "Customer Lastname 2",
      "address": "Address 2",
      "id": 3
    },
    ....

As you can see, loading a large number of records takes some time (between 150 to 1224 ms on my machine) on the first load, but then drops to 0 ms for subsequent calls because we put the data in our cache.

In our app example, we set a cache expiration value of 20 seconds, so once the 20 seconds are up, we will reload the data from the database and cache it for the next 20 seconds.

Conclusion

In the example we just saw, it was a small application that tries to retrieve a large number of data that we are going to put in a memory cache.
In the case of distributed applications you will have to use a distributed cache such as Redis or memcached.
You can find in the link below a very small application that uses Redis :
https://github.com/kbourzayq/RedisDemo

The idea of this example is to explain how we can implement the Repository pattern by caching the data to have high performance in the case where we have data that has a very minimal change frequency.
I hope this article was clear for you and do not hesitate to leave your comments if you see that it needs improvements.

See you next post in the next few days.