The acronym 'SOLID' is a collection of rules and principles that every good Object oriented program should follow. This post focuses on the Single Responsibility Principle and examples of good and bad implementations in C#. The other principles will be covered in later blog posts.
The Single Responsibility Principle states that a class should only do one thing. When classes do too many things it makes code harder to maintain. The class bellow does not follow the Single Responsibility Principle:
class AmericanoMaker
{
void grindCoffeeBeans()
{
Console.WriteLine("Grinding the coffee beans...");
}
public void makeDrink()
{
grindCoffeeBeans();
Console.WriteLine("Done! your coffee is ready :)");
}
}
Figure 1: A class that simulates making a tasty americano for the user.
The class shown in figure 1 does too many things. It is not only responsible for making an americano. It also needs to grind the coffee beans. This ultimately makes the code harder to maintain. The example makes more sense after introducing another class to the application.
class CappuccinoMaker
{
void grindCoffeeBeans()
{
Console.WriteLine("Grinding the Coffee Beans...");
}
void steamMilk()
{
Console.WriteLine("Steaming the milk...");
}
public void makeDrink()
{
grindCoffeeBeans();
steamMilk();
Console.WriteLine("Done! your coffee is ready :)");
}
}
Figure 2: A class that simulates making a delicious cappuccino for the user
Figure 2 shows another class that does too many things. Since the class grinds coffee beans, steams milk and makes a cappuccino.
You may have noticed here that something horrible has happened after introducing this new class! Both classes now have a grindCoffeeBeans method. Duplicate code is bad in software development as any changes in one method need to be done to the other. This effectively is the reason why classes that do one thing are easier to maintain. If classes only have one functionality it is a lot harder to make duplicate code. So with the drawbacks of the older examples examined lets take a look at a better implementation of a coffee simulator.
class MilkSteamer
{
public void steamMilk()
{
Console.WriteLine("Steaming the milk...");
}
}
class CoffeeGrinder
{
public void grindCoffeeBeans()
{
Console.WriteLine("Grinding coffee beans...");
}
}
class CapuccinoMaker
{
private CoffeeGrinder coffeeGrinder;
private MilkSteamer milkSteamer;
public void makeDrink()
{
coffeeGrinder.grindCoffeeBeans();
milkSteamer.steamMilk();
Console.WriteLine("Done! your coffee is ready :)");
}
}
class AmericanoMaker
{
private CoffeeGrinder coffeeGrinder;
public void makeDrink()
{
coffeeGrinder.grindCoffeeBeans();
Console.WriteLine("Done! your coffee is ready :)");
}
}
Figure 3: A beautifully designed class system that makes delicious coffee.
The new class design separates the functionality of steaming milk and grinding coffee into their own classes. This simple change has fixed the duplicate code disaster discussed earlier. This is because, the AmericanoMaker and CappuccinoMaker classes now use the same method on the CoffeeGrinder class to grind their coffee. Therefore any changes to the coffee bean grinding process only need to be done to the CoffeeGrinder class.
As a general rule if you find yourself having methods that do the same thing in different parts of your application, the design of your app could probably be improved. Well designed classes do not have repeated code.
Conclusion
This blog post has discussed the benefits of following the Single Responsibility principle using some example classes. We have learnt that writing classes that do one thing leads to a more maintainable codebase.
This blog post is the first in a series of posts focused around the SOLID design principles so stay tuned for more tips on designing brilliant object oriented applications!
Thank you very much for reading and don't hesitate to ask questions down bellow and I can attempt to answer them ! 😄
More Resources
Here is a list of other resources that are very useful for designing good object oriented programs.
Top comments (0)