Keeping Code Flexible with the Liskov Substitution Principle
Akash Thakur
Specialist - Product Engineering @ LTIMindtree | ??.NET core | ?? Azure Certified x 5 | ?? Proficient in Angular | Open to Embrace React ?? ??
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.
Lead Software Engineer | MVC.NET | .NET CORE | JavaScript | TypeScript | Angular | ASP.NET | MS-SQL SERVER | Agile | Web API
5 个月Very informative
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
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