Keeping Code Flexible with the Liskov Substitution Principle

Keeping Code Flexible with the Liskov Substitution Principle

Imagine you're playing with a set of toy cars. Some are police cars, others are fire trucks, but they all fit on the same toy track. In programming, we have a similar idea called the Liskov Substitution Principle (LSP). It's like saying, "Any toy car should be able to roll on the track, no matter what type it is."

When Things Go Right

Let's talk about a team of workers. We have a general worker, a manager, and a developer. They all have jobs to do:

// General worker does general stuff
public class Employee {
    // ...
    public void Work() {
        Console.WriteLine("Working on general tasks.");
    }
}

// Manager organizes the team
public class Manager : Employee {
    public void Work() {
        Console.WriteLine("Managing the team.");
    }
}

// Developer writes code
public class Developer : Employee {
    public void Work() {
        Console.WriteLine("Writing code.");
    }
}        

In this setup, everyone is doing their part, and you can expect any worker to do some kind of job without any surprises. This is LSP in action. You can tell any worker to "Work!" and they'll do what they're supposed to do.


When Things Go Wrong

Now, let's say we bring an intern into the mix. Interns are still learning, so they can't do everything on their own. If we tell our intern to "Work!" like everyone else, but they can't, we've got a problem:

// Intern needs supervision
public class Intern : Employee {
    public void Work() {
        throw new Exception("Can't work alone!");
    }
}        

If we try to use the intern the same way we use a manager or a developer, our program will crash. That's not good, and it breaks our LSP rule.


Fixing the Problem with Interfaces

To fix this, we can use something called an interface. It's like a promise that certain workers can do certain jobs. We create a special "IWork" promise for jobs that can be done without help:

// Promise to do work
public interface IWork {
    void Work();
}

// Manager and Developer make the promise
public class Manager : Employee, IWork {
    // ...
}

public class Developer : Employee, IWork {
    // ...
}

// Intern doesn't make the promise
public class Intern : Employee {
    // ...
}        

Now, only workers who make the "IWork" promise can be told to "Work!" This way, we never accidentally tell an intern to do a job they can't handle. Everyone else, like the manager and developer, can still do their work as expected.

In Short

The Liskov Substitution Principle helps us make sure that our program can use different types of workers interchangeably without running into problems. When we have a worker that doesn't fit the mold, like our intern, we use interfaces to make sure we only assign tasks to those who can handle them. This keeps our code flexible and reliable, just like how any toy car should be able to roll on the track.

Sarang Mukewar

Lead Software Engineer | MVC.NET | .NET CORE | JavaScript | TypeScript | Angular | ASP.NET | MS-SQL SERVER | Agile | Web API

5 个月

Very informative

回复
Roma Rathi

I Lead Software Engineer | Azure Certified | Scrum | C# | Angular 2-12 | Entity Framework | SQL Server | HTML/CSS | Web API's | MVC Framework | .Net Core | Microservices | In the Process of exploring DevOps

5 个月

Very informative

Nikhil Rajput

Junior Engineer at Cornerstone OnDemand | CDAC | SDET | QA(ISTQB) | Automation(Playwright, Selenium) | Java | SQL | DevOps (CI/CD, Jenkins, Docker) | Cloud Devops & Security Enthusiast

5 个月

Insightful

要查看或添加评论,请登录

Akash Thakur的更多文章

  • Dependency Inversion Principle

    Dependency Inversion Principle

    The Dependency Inversion Principle (DIP) is one of the five SOLID principles of object-oriented programming that enable…

    1 条评论
  • Open/Closed Principle (OCP)

    Open/Closed Principle (OCP)

    The Open/Closed Principle is one of the SOLID principles of object-oriented design. It states that software entities…

社区洞察

其他会员也浏览了