Single Responsibility Principle Explained

Matthew Honour — Thu, 03 Sep 2020 14:27:57 +0000

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.

Type Conversion in C#

Matthew Honour — Mon, 24 Aug 2020 15:16:55 +0000

C# is a language with many types such as ints, strings and too many others to fit in this sentence 😅 Sometimes while working in C# you'll find yourself needing to convert between these types so, this blog will tell you all you need to know about type conversion in C#.

There are three ways that types are converted in C#:

1. Implicit Type Conversion

Implicit type conversion occurs automatically by the compiler when you are converting between types where no data loss can occur. For example if you are converting an 'int' to a 'long', the C# compiler will do this automatically. This is because, the 'long' data type can hold values up to 9223372036854775807 which is much larger than the maximum value the 'int' data type can store (2147483647). Since there is no chance for data loss, the variables can be casted automatically as shown bellow:

// implicit type conversion as ints are smaller than longs.
int a = 1;
long b = a;

2. Explicit Type Conversion

Explicit type conversion is used where data loss is possible. This type conversion is not automatically done by the compiler as it warns you that data loss may occur. Therefore you need to explicitly tell the compiler that you recognize that data loss may occur but you still want to go through with the conversion anyway. This process is also referred to as casting. An example of explicit type conversion is shown below:

// explicit type conversion with no data loss.
long c = 1;
int d = (int)c;

// explicit type conversion with data loss.
// overflow occurs as value of e is too large to be stored in variable f.
long e = 1000000000000000000;
int f = (int)e;

3. Converting Between Non Compatible Types

Some types in C# cannot be implicitly or explicitly converted between one another. A popular example of this is converting a string to an int as shown bellow:

string s = "123";
int i = (int)s;

/* the following compiler error is shown:

Cannot convert type 'string' to 'int' [PlaygroundUI]csharp(CS0030)

*/

In times like this where you need to convert from a string to another primitive type, you can instead use methods made available in the 'Convert' .NET Core library. You can also use methods available in the primitive type itself. Examples of using these methods are shown below:

// conversion using the Parse() method in the primitive types:

int i = int.Parse("123");

bool b = bool.Parse("true");

// conversion using the methods in the 'Convert' class:

int convertedInt = Convert.ToInt32("123");

bool convertedBool = Convert.ToBoolean("true");

// ... more methods available for all other primitive types.

To Conclude...

I hope this blog helped you understand how type conversion works in C#. Thanks for reading! 😄

DEV Community: Matthew Honour