Applying Liskov Substitution and Interface Segregation for Class Redesign

1. Liskov Substitution Principle (LSP)

The Liskov Substitution Principle is a powerful guideline for ensuring your inheritance structures are semantically correct. It was formulated by Barbara Liskov and states:

Subtypes must be substitutable for their base types without altering the correctness of the program.

In simpler terms, if a function expects an object of a base class, it should be able to work with an object of any of its derived classes without causing errors or unexpected behavior. If you find yourself writing if (object is TypeA) checks before using a derived class, you are likely violating LSP.

A violation often occurs when a subclass changes the behavior of a method it inherits in a way that the parent class contract did not anticipate—for example, by throwing a new exception or doing nothing when something was expected to happen.

To see this principle in action, let's watch a video that covers two classic examples.

The core takeaway is that inheritance should represent a true "is-a" relationship not just in structure, but in behavior. A Square is a Rectangle mathematically, but from a behavioral standpoint in that code example, it wasn't a substitutable Rectangle.

Redesigning a Hierarchy with LSP

Let's look at a more complex, business-oriented scenario. This will show how LSP guides us to a better design using interfaces and abstract classes, a common task when building enterprise systems.

This refactoring is a perfect example of moving to an architectural mindset. Instead of patching the problem with a conditional check, the entire class structure was re-evaluated and rebuilt around well-defined contracts (interfaces), resulting in a system that is both correct and flexible.

2. Interface Segregation Principle (ISP)

The Interface Segregation Principle is about keeping interfaces lean and focused. It states:

Clients should not be forced to depend on interfaces they do not use.

This principle tackles the problem of "fat interfaces"—large interfaces that contain methods for many different responsibilities. When a class implements such an interface, it is often forced to provide empty or exception-throwing implementations for methods it doesn't need. This is a sign of poor cohesion and a violation of ISP.

The solution is to break down fat interfaces into smaller, more specific ones based on the roles clients play.

This approach leads to a more modular system where classes only know about the methods that are relevant to them.

interface IRepositoryActions {
  commit(message: string): void;
  push(): void;
  createPullRequest(title: string): void;
  approvePullRequest(id: number): void;
  mergePullRequest(id: number): void;
}

Conclusion

In this lesson, we've added two powerful principles to our design toolkit that guide us in creating high-quality abstractions.

Key Takeaways:

• Liskov Substitution Principle (LSP): Ensures that inheritance hierarchies are behaviorally sound. A subclass must be truly substitutable for its superclass without breaking the program. This often means preferring composition or more granular abstractions over incorrect inheritance.
• Interface Segregation Principle (ISP): Pushes us to create small, cohesive interfaces instead of large, "fat" ones. This prevents clients from depending on methods they don't use and makes the system more modular and decoupled.
• Redesigning Hierarchies: We saw through practical examples how applying LSP and ISP leads to redesigning class hierarchies by breaking down classes and interfaces into smaller, more focused units that better represent the roles and capabilities within the system.

Preview of the Next Lesson:
We are now ready to tackle the final SOLID principle: the Dependency Inversion Principle (DIP). This principle addresses how high-level and low-level modules should interact. It will tie together everything we've learned about abstractions and help us build truly decoupled, flexible, and pluggable software architectures.