SOLID design principles in .NET: the Single Responsibility Principle

The SOLID design principles are a collection of best practices for object oriented software design. The abbreviation comes from the first letter of each of the following 5 constituents:

Single responsibility principle (SRP)

Open-Closed principle (OCP)

Liskov substitution principle (LSP)

Interface segregation principle (ISP)

Dependency inversion principle (DIP)

Each of these terms are meant to make your code base easier to understand and maintain. They also ensure that your code does not become a mess with a large degree of interdependency that nobody wants to debug and extend. Of course you can write functioning software without adhering to these guidelines but they are a good investment in the future development of your product especially as far as maintainability and extensibility are concerned. Also, by following these points your code will become more object oriented instead of employing a more procedural style of coding with a lot of magic strings and enumerations and other primitives.

However, the principles do not replace the need for maintaining and refactoring your code so that it doesn’t get stale. They are a good set of tools to make your future work with your code easier. We will look at each of these in this series.

You can view these principles as guidelines. You should write code with these guidelines in mind and should aim to get as far as possible to reach each of them. You won’t always succeed of course, but even a bit of SOLID is more than the total lack of it.

SRP introduction

The Single Responsibility Principle states that every object should only have one reason to change and a single focus of responsibility. In other words every object should perform one thing only. You can apply this idea at different levels of your software: a method should only carry out one action; a domain object should only represent one domain within your business; the presentation layer should only be responsible for presenting your data; etc. This principle aims to achieve the following goals:

Short and concise objects: avoid the problem of a monolithic class design that is the software equivalent of a Swiss army knife

Testability: if a method carries out multiple tasks then it’s difficult to write a test for it

Readability: reading short and concise code is certainly easier than finding your way through some spaghetti code

Easier maintenance

A responsibility of a class usually represents a feature or a domain in your application. If you assign many responsibilities to a class or bloat your domain object then there’s a greater chance that you’ll need to change that class later. These responsibilities will be coupled together in the class making each individual responsibility more difficult to change without introducing errors in another. We can also call a responsibility a “reason to change”.

SRP is strongly related to what is called Separation of Concerns (SoC). SoC means dissecting a piece of software into distinct features that encapsulate unique behaviour and data that can be used by other classes. Here the term ‘concern’ represents a feature or behaviour of a class. Separating a programme into small and discrete ‘ingredients’ significantly increases code reuse, maintenance and testability.

Other related terms include the following:

Cohesion: how strongly related and focused the various responsibilities of a module are

Coupling: the degree to which each programme module relies on each one of the other modules

In a good software design we are striving for a high level of cohesion and a low level of coupling. A high level of coupling, also called tight coupling, usually means a lot of concrete dependency among the various elements of your software. This leads to a situation where changing the design of one class leads to the need of changing other classes that are dependent on the class you’ve just changed. Also, with tight coupling changing the design of one class can introduce errors in the dependent classes.

One last related technique is Test Driven Design or Test Driven Development (TDD). If you apply the test first approach of TDD and write your tests carefully then it will help you fulfil SRP, or at least it is a good way to ensure that you’re not too far from SRP. If you don’t know what TDD is then you can read about it here.

Demo

In the demo we’ll simulate an e-commerce application. We’ll first deliberately introduce a bloated Order object with a lot of responsibilities. We’ll then refactor the code to get closer to SRP.

Open Visual Studio and create a new console application. Insert a new folder called Model and insert a couple of basic models into it:

These are two very simple services with no real implementation that only throw exceptions.

Looking at the Order class we see that it performs a lot of stuff: checking out after the customer has placed an order, sending emails, logging exceptions, charging the credit card etc. Probably the most important method here is Checkout which calls upon the other methods in the class.

What is the problem with this design? After all it works well, customers can place orders, they get notified etc.

I think first and foremost the greatest flaw is a conceptual one actually. What has the Order domain object got to do with sending emails? What does it have to do with checking the inventory, logging exceptions or charging the credit card? These are all concepts that simply do not belong in an Order domain.

Imagine that the Order object can be used by different platforms: an e-commerce website with credit card payments or a physical shop where you pick your own goods from the shelf and pay by cash. Which leads to several other issues as well:

Cheque payments don’t need card processing: cards are only charged in the Checkout method if the customer is paying by card – in any other case we should not involve the idea of card processing at all

Inventory reservations should be carried out by a separate service in case we’re buying in a physical shop

The customer will probably only need an email notification if they use the web platform of the business – otherwise the customer won’t even provide an email address. After all, why would you want to be notified by email if you buy the goods in person in a shop?

The problem here is that no matter what platform consumes the Order object it will need to know about the concepts of inventory management, credit card processing and emails. So any change in these concepts will affect not only the Order object but all others that depend on it.

Let’s refactor to a better design. The key is to regroup the responsibilities of the Checkout method into smaller units. Add a new folder called SRP to the project so that you’ll have access to the objects before and after the refactoring.

We know that we can process several types of Order: an online order, a cash order, a cheque order and possibly other types of Order that we haven’t thought of. This calls for an abstract Order object:

So we separated out the inventory management, customer notification and payment services into their respective interfaces. We can now create some concrete Order objects. The simplest case is when you go to a shop, place your goods into a real shopping cart and pay at the cashier. There’s no credit card process and no email notification. Also, the inventory has probably been reduced when the goods were placed on the shelf, there’s no need to reduce the inventory further when the actual purchase happens:

The credit card payment must be processed hence we’ll need a Payment service to take care of that. We call upon its ProcessCreditCard method in the overridden Checkout method. Here the consumer platform can provide some concrete implementation of the IPaymentService interface, it doesn’t matter to the Order object.

Lastly we can have an online order with inventory management, payment service and email notifications:

The consumer application will provide concrete implementations for the notification, inventory management and payment services. The OnlineOrder object will not care what those implementations look like and will not be affected at all if you make a change in those implementations or send in a different concrete implementation. As you can see these are the responsibilities that are likely to change over time. However, the Order object and its concrete implementations won’t care any more.

Furthermore, a web platform will only concern itself with online orders now and not with point-of-sale ones such as CreditOrder and CashOrder. The platform that a cashier uses in the shop will probably use CashOrder and CreditOrder objects depending on the payment method of the customer. The web and point-of-sale platforms will no longer be affected by changes made to the inventory management, email notification and payment processing logic.

Also, note that we separated out the responsibilities into individual smaller interfaces and not a single large one with all responsibilities. This follows the letter ‘I’ in solid, the Interface Segregation Principle, that we’ll look at in a future post.

We are done with the refactoring, at least as far as SRP is concerned. We can still take up other areas of improvement such as making the Order domain object cleaner by creating application services that will take care of the Checkout process. It may not be correct to put all these services in a single domain object, but it depends on the philosophy you follow in your domain design. That leads us to discussions on DDD (Domain Driven Design) which is not the scope of this post.

18 Responses to SOLID design principles in .NET: the Single Responsibility Principle

How would these objects be used in a shop that accepts cash, credit card or check? What would the calling code look like? I’m explaining OOP concepts to a life-long DIBOL programmer and he raised this question. This is the first article I’ve read by you. It is truly excellent and I plan to read more of your posts.

It’s difficult to provide a complete answer in a small comment box, so I’ll try and give you a short one. If you mean how we glue together the different services and other components, such as repositories and domains, then you’ll need to be patient. I’ve started working on a skeleton web API app that will demonstrate how a layered OOP solution could look like + show how to inject concrete implementations from the composition root. Right now I have 4 more posts on SOLID waiting in the pipeline so it will be at least 2 more weeks before I start publishing the posts of the next series. It will span a lot of posts, possibly 10 or even more. I’m planning to pack it with concepts from SOLID and Domain Driven Design.

If you on the other hand mean how to determine whether we’re dealing with a Cash, a CreditCard or a Check order then the answer is different. It is not known during compile time how the customer is going to pay, so the exact Order type cannot be determined. Constructing implementations of abstractions at runtime can be solved in various ways, but an abstract factory is usually the way to go.
//Andras

Finally I found a website that explains SRP well. Thank you sir. I was looking at Uncle Bob’s book and I was saying to myself I don’t care about rectangles and drawing rectangles I need something I can truly grasp. I can get my mind around orders, because it is something we all normally do.

Hi Andras
Thanks for your feedback. What I meant was that OnlineOrder class makes call to Payment Service, Inventory service and Notification Service. Are these services are exposed as WCF/WEB API services? If so, OnlineOrder service makes local call to consume this service? or If thye are going to be RPC calls, will it be time consuming in order to complete this checkout process? Hope my question is clear to you.

That depends where you put your backend logic. “Service” in a layered project doesn’t necessarily mean that it lies on a different server, like a public API. It is often a local file that is called upon directly by the consumer, e.g. a Controller in an MVC app. If you put your services on a different server then of course the total response time will take longer. However, these are infrastructure considerations that are independent of SOLID and the SRP.
//Andras

Thank you Andras!, Very well explained and understandable post. I have a doubt about the order object, You use it as a domain object but not as a domain model isn’t it? The order object uses services to perform specific actions, Do these services should contain business logic? I understand that these services should be used for a example in a controller, but in what place the order object should be used? Inside of the service or in the controller? Should the order object be wrapped in a service? Should both domain object and service contain business logic? I am beginning with software architecture principles and for now I’m confused with basic concepts like those. I would appreciate your comments.

Scroll down to the section called Domain Driven Design. You’ll see two sub-sections, one called Original skeleton project and then DDD revisited. They are quite lengthy but you’ll find a general guideline about how to organise your application into services, repos, controllers, domain objects and what their roles are.
//Andras