DEV Community: Francis Terrero

Mastering SOLID Principles in C#

Francis Terrero — Sun, 07 Jul 2024 17:04:11 +0000

As a backend developer, there are some concepts that you must know. If you want a job in this industry, the SOLID principles are a set of guidelines that have stood the test of time and are crucial to understand. They are also common interview topics that you must answer correctly if you want to pass.

I'm going to explain all the principles to you in the easiest way I found, using anime-related examples.

Single Responsibility Principle

A class should have only one reason to change

Not only your class; your functions and modules should have one responsibility. This means that if you have a big function that does a lot of things, you should probably separate it into smaller functions.

public class Anime
{
    public string Title { get; set; }
    public string Genre { get; set; }
    public int NumberOfEpisodes { get; private set; }
    public string Studio { get; set; }
    public string Director { get; set; }
    public List<string> MainCharacters { get; private set; }
    public List<string> Episodes { get; private set; }

    public Anime(string title, string genre, string studio, string director)
    {
        Title = title;
        Genre = genre;
        Studio = studio;
        Director = director;
        MainCharacters = new List<string>();
        Episodes = new List<string>();
        NumberOfEpisodes = 0;
    }

    public void AddCharacter(string character)
    {
        MainCharacters.Add(character);
    }

    public void AddEpisode(string episode)
    {
        Episodes.Add(episode);
        NumberOfEpisodes++;
    }
}

Look at this class. This class manages Episodes and Characters. These fields can be turned into classes easily.

Now let's split these properties by creating their own classes:

public class Character
{
    public string Name { get; set; }

    public Character(string name)
    {
        Name = name;
    }

    public void DisplayInfo()
    {
        Console.WriteLine($"Character: {Name}");
    }
}

public class Episode
{
    public string Title { get; set; }

    public Episode(string title)
    {
        Title = title;
    }

    public void DisplayInfo()
    {
        Console.WriteLine($"Episode: {Title}");
    }
}

public class Anime
{
    public string Title { get; set; }
    public string Genre { get; set; }
    public int NumberOfEpisodes { get { return Episodes.Count; } }
    public string Studio { get; set; }
    public string Director { get; set; }
    public List<Character> MainCharacters { get; private set; }
    public List<Episode> Episodes { get; private set; }

    public Anime(string title, string genre, string studio, string director)
    {
        Title = title;
        Genre = genre;
        Studio = studio;
        Director = director;
        MainCharacters = new List<Character>();
        Episodes = new List<Episode>();
    }

    public void AddCharacter(Character character)
    {
        MainCharacters.Add(character);
    }

    public void AddEpisode(Episode episode)
    {
        Episodes.Add(episode);
    }
}

Here, there is a new Character and Episode class, separating the responsibility of the Anime class.

If you want to split the class more, you can create Studio, Director, and even Genre classes too!

Open-Closed Principle

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

You should not modify the class if you want to add new features!

public class AnimeCharacter {

    // Create a goal for each character
    public string GokuGoal() { 
        return "Save the planet";
    }
    public string GojoGoal() {
        return "Defeat Sukuna";
    }
    public string GokuSpecialAttack() {
        return "Kamehameha!!";
    }
    public string GojoSpecialAttack() {
        return "Domain expansion";
    }
}

Here, this class has a Goal() and a SpecialAttack() for each character, meaning that if we want to add another Goal() or SpecialAttack(), you'll have to modify the class each time.

public abstract class AnimeCharacter
{
    //SpecialAttack() is now an abstract method
    public abstract string SpecialAttack(); 

    public virtual string Goal() {
        return "Save the planet";
    }
}

public class Goku : AnimeCharacter {

    // Can now override SpecialAttack() from AnimeCharacter
    public override string SpecialAttack() { 
        return "Kamehameha!!";
    }
}

public class Gojo : AnimeCharacter {

    public override string SpecialAttack() {
        return "Domain expansion";
    }

    public override string Goal() {
        return "Defeat Sukuna";
    }
}

Apply inheritance and extend its functionality. Now, there are new Gojo and Goku classes that inherit from AnimeCharacter, overriding each implementation in its child class!

If you want to know more about abstraction and inheritance, I have a post prepared for you!

Liskov Substitution Principle

Derived or child classes must be substitutable for their base or parent classes

The methods of the parent class should be replaceable by methods of the child class.

public class StrawHat
{
    public virtual void Attack()
    {
        Console.WriteLine("StrawHat attacks.");
    }

    public virtual void Heal()
    {
        Console.WriteLine("StrawHat heals.");
    }
}

public class Chopper : StrawHat
{
    public override void Attack()
    {
        Console.WriteLine("Chopper attacks with his devil fruit power.");
    }

    public override void Heal()
    {
        Console.WriteLine("Chopper heals with his medical skills.");
    }
}

public class Usopp : StrawHat
{
    public override void Attack()
    {
        Console.WriteLine("Usopp attacks with his slingshot.");
    }

    public override void Heal()
    {
        // This will break the principle of LSP. Usopp cannot heal.
        throw new NotImplementedException("Usopp doesn't heal.");
    }
}

All StrawHats but Chopper know nothing about medicine and healing, like Usopp, so you shouldn't add the method Heal in the parent class StrawHat.

Instead, you should split the skills by interfaces, like this:

public interface IAttacker
{
    void Attack();
}

public interface IHealer
{
    void Heal();
}

public class Chopper : IHealer, IAttacker
{
    public void Heal()
    {
        Console.WriteLine("Chopper heals with his medical skills.");
    }

    public void Attack()
    {
        Console.WriteLine("Chopper attacks with his devil fruit power.");
    }
}

public class Usopp : IAttacker
{
    public void Attack()
    {
        Console.WriteLine("Usopp attacks with his slingshot.");
    }
}

Now, the methods are separated by interfaces where you can implement the contract wherever you need it. This comes along with the next Interface Segregation Principle.

Interface Segregation Principle

Do not force any client to implement an interface which is irrelevant to them

In simple words: do not create a "super" interface. This principle comes along with the Single Responsibility Principle.

public interface IAnimeCharacter
{
    string Name { get; set; }
    string Power { get; set; }
    void Display();
    void Attack();
    void Defend(); // Not all characters may need this method
}

public class Hero : IAnimeCharacter
{
    public string Name { get; set; }
    public string Power { get; set; }
    public string HeroicTitle { get; set; }

    public void Display()
    {
        Console.WriteLine($"Hero: {Name}, Title: {HeroicTitle}, Power: {Power}");
    }

    public void Attack()
    {
        Console.WriteLine($"Hero {Name} attacks heroically with {Power}!");
    }

    public void Defend()
    {
        Console.WriteLine($"Hero {Name} defends bravely!");
    }
}

public class Villain : IAnimeCharacter
{
    public string Name { get; set; }
    public string Power { get; set; }
    public string EvilPlan { get; set; }

    public void Display()
    {
        Console.WriteLine($"Villain: {Name}, Plan: {EvilPlan}, Power: {Power}");
    }

    public void Attack()
    {
        Console.WriteLine($"Villain {Name} attacks maliciously with {Power}!");
    }

    public void Defend()
    {
        // Villain may not have a defend action
        throw new NotImplementedException($"{Name} does not defend!");
    }
}

The Villain class implements the interface IAnimeCharacter even when the class does not need the Defend() function.

public interface ICharacter
{
    string Name { get; set; }
    string Power { get; set; }
    void Display();
}

public interface IAttackable
{
    void Attack();
}

public interface IDefendable
{
    void Defend();
}

public class Hero : ICharacter, IAttackable, IDefendable
{
    public string Name { get; set; }
    public string Power { get; set; }
    public string HeroicTitle { get; set; }

    public void Display()
    {
        Console.WriteLine($"Hero: {Name}, Title: {HeroicTitle}, Power: {Power}");
    }

    public void Attack()
    {
        Console.WriteLine($"Hero {Name} attacks heroically with {Power}!");
    }

    public void Defend()
    {
        Console.WriteLine($"Hero {Name} defends bravely!");
    }
}

public class Villain : ICharacter, IAttackable


{
    public string Name { get; set; }
    public string Power { get; set; }
    public string EvilPlan { get; set; }

    public void Display()
    {
        Console.WriteLine($"Villain: {Name}, Plan: {EvilPlan}, Power: {Power}");
    }

    public void Attack()
    {
        Console.WriteLine($"Villain {Name} attacks maliciously with {Power}!");
    }
}

Now, there are three new interfaces: ICharacter, IAttackable, and IDefendable, where you can use them where you really need them.

If you don't apply the Single Responsibility Principle, the Interface Segregation Principle won't be effective either.

Dependency Inversion Principle

High-level modules should not depend on low-level modules. Both should depend on abstractions

Abstractions should not depend on details. Details (concrete implementations) should depend on abstractions.

This is very useful because you will be able to change low-level implementations without affecting high-level modules, making high-level modules independent of low-level modules.

public class Hero
{
    public string Name { get; set; }
    public string Power { get; set; }
    public string HeroicTitle { get; set; }

    public void Display()
    {
        Console.WriteLine($"Hero: {Name}, Title: {HeroicTitle}, Power: {Power}");
    }

    public void Attack()
    {
        Console.WriteLine($"Hero {Name} attacks heroically with {Power}!");
    }

    public void Defend()
    {
        Console.WriteLine($"Hero {Name} defends bravely!");
    }
}

public class Villain
{
    public string Name { get; set; }
    public string Power { get; set; }
    public string EvilPlan { get; set; }

    public void Display()
    {
        Console.WriteLine($"Villain: {Name}, Plan: {EvilPlan}, Power: {Power}");
    }

    public void Attack()
    {
        Console.WriteLine($"Villain {Name} attacks maliciously with {Power}!");
    }
}

public class AnimeBattle
{
    private readonly Hero _hero;
    private readonly Villain _villain;

    public AnimeBattle(Hero hero, Villain villain)
    {
        _hero = hero;
        _villain = villain;
    }

    public void StartBattle()
    {
        _hero.Display();
        _villain.Display();
        _hero.Attack();
        _villain.Attack();
        _hero.Defend();
    }
}

Here, I'm implementing Hero and Villain classes directly. Any change in either the Hero class or the Villain class (low-level) can break the AnimeBattle class (high-level).

public interface IAnimeCharacter
{
    string Name { get; set; }
    string Power { get; set; }
    void Display();
    void Attack();
}

public interface IHero : IAnimeCharacter
{
    string HeroicTitle { get; set; }
    void Defend();
}

public interface IVillain : IAnimeCharacter
{
    string EvilPlan { get; set; }
}

public class Hero : IHero
{
    public string Name { get; set; }
    public string Power { get; set; }
    public string HeroicTitle { get; set; }

    public void Display()
    {
        Console.WriteLine($"Hero: {Name}, Title: {HeroicTitle}, Power: {Power}");
    }

    public void Attack()
    {
        Console.WriteLine($"Hero {Name} attacks heroically with {Power}!");
    }

    public void Defend()
    {
        Console.WriteLine($"Hero {Name} defends bravely!");
    }
}

public class Villain : IVillain
{
    public string Name { get; set; }
    public string Power { get; set; }
    public string EvilPlan { get; set; }

    public void Display()
    {
        Console.WriteLine($"Villain: {Name}, Plan: {EvilPlan}, Power: {Power}");
    }

    public void Attack()
    {
        Console.WriteLine($"Villain {Name} attacks maliciously with {Power}!");
    }
}

public class AnimeBattle
{
    private readonly IHero _hero;
    private readonly IVillain _villain;

    public AnimeBattle(IHero hero, IVillain villain)
    {
        _hero = hero;
        _villain = villain;
    }

    public void StartBattle()
    {
        _hero.Display();
        _villain.Display();
        _hero.Attack();
        _villain.Attack();
        _hero.Defend();
    }
}

Now, any class that implements IHero or IVillain can be used in the AnimeBattle class, providing a flexible way to have different implementations and taking advantage of polymorphism.

Here's the source code if you want to play with it!

Happy coding!

The key of OOP Principles

Francis Terrero — Wed, 19 Jun 2024 02:47:56 +0000

As time passes, the way we develop software changes. It comes with new programming languages, frameworks, libraries, and now paradigms. Object-oriented programming came to change how we build our apps, providing a more maintainable, reusable, and scalable way to build. But in order to do that, you must know all the basics. That's why I am going to teach the four principles of OOP.

Abstraction

Abstraction essentially hides complex implementations and only shows the necessary features of an object.

Within this principle, there are two key topics we must know about:

Abstract Class: Can't be instantiated and can have abstract methods that must be overridden in the implementing class.

public abstract class AnimeCharacter {

    public abstract string SpecialAttack();

    public virtual string Goal() {
        return "Save the planet";
    }
}

public class Goku : AnimeCharacter {

    public override string SpecialAttack() {
        return "Kamehameha!!";
    }
}

public class Gojo : AnimeCharacter {

    public override string SpecialAttack() {
        return "Domain expansion";
    }

    public override string Goal() {
        return "Defeat Sukuna";
    }
}

So, what's this virtual keyword 🤔? It allows setting default implementations for methods that can be overridden.

Interfaces: A contract that the implementing class must define.

public interface IMovable {

   string Move();
}

public class Goku : IMovable {

    public string Move() {
        return "Fly";
    }
}

public class Luffy : IMovable {

    public string Move() {
        return "Run";
    }
}

Encapsulation

Encapsulation is a shield that prevents a piece of code from being accessed outside its scope.

With access modifiers, you can restrict access to your code:

Public: The code has no restrictions.
Private: The code can only be accessed within the class itself.
Protected: Only the superclass and subclass can access the code.
Internal: The code has restrictions within the same assembly/project.

    public class AnimeCharacter {

        // Private field
        private string secretTechnique;

        // Public property
        public string Name { get; set; }

        // Protected property
        protected string Rank { get; set; }

        // Public method to set the private field
        public void SetSecretTechnique(string technique) {
            secretTechnique = technique;
        }

        // Public method to get the private field
        public string GetSecretTechnique() {
            return secretTechnique;
        }
    }

    public class Ninja : AnimeCharacter {

        // Public method to access the protected property
        public void SetRank(string rank) {
            Rank = rank;
        }

        // Public method to get the protected property
        public string GetRank() {
            return Rank;
        }
    }

    var naruto = new Ninja();
    naruto.Name = "Naruto Uzumaki";
    naruto.SetSecretTechnique("Shadow Clone Jutsu");
    naruto.SetRank("Genin");

    naruto.Name; // Outputs "Naruto Uzumaki"
    naruto.GetSecretTechnique() // Outputs "Shadow Clone Jutsu"
    naruto.GetRank(); // Outputs "Genin"

Inheritance

Inheritance allows methods and properties to be inherited from another class.

Superclass or Parent Class

public class Minato {

   public string HairColor = "yellow";

   public string Attack() {
       return "Rasengan!!";
   }
}

Subclass or Child Class

public class Naruto : Minato {
   public string FavoriteFood = "ramen";

   public string Attack() {
       return "Rasengan!!";
   }
}

var naruto = new Naruto();
naruto.HairColor; // Outputs "yellow"

Polymorphism

Polymorphism allows classes to have different implementations of methods that are called by the same name.

It comes in two forms:

Compile-time (method overload)

public class Zoro {

    // Method overload for attack
    public string Attack(int swords) {
        return $"Attacks with {swords} swords.";
    }

    // Method overload for a named attack
    public string Attack(string technique) {
        return $"Uses the technique {technique}.";
    }
}

var zoro = new Zoro();
zoro.Attack(3);                // Outputs "Attacks with 3 swords."
zoro.Attack("Santoryu Ogi");   // Outputs "Uses the technique Santoryu Ogi."

Run-time (method override)

public class AnimeCharacter {

    public virtual string SpecialMove() {
        return "Basic Attack";
    }
}

public class Ichigo : AnimeCharacter {

    public override string SpecialMove() {
        return "Getsuga Tensho";
    }
}

public class Sasuke : AnimeCharacter {

    public override string SpecialMove() {
        return "Chidori";
    }
}

AnimeCharacter ichigo = new Ichigo();
AnimeCharacter sasuke = new Sasuke();
ichigo.SpecialMove();  // Outputs "Getsuga Tensho"
sasuke.SpecialMove();  // Outputs "Chidori"

Conclusion

Now you know the four principles of Object-Oriented Programming: Encapsulation, which allows you to restrict access by scope; Abstraction, which shows valuable features while hiding complex implementations; Inheritance, which enables you to reuse fields and methods; and Polymorphism, which allows you to change behavior at compile time and run time. Happy coding!