Liskov substitution principle facts for kids
The Liskov substitution principle (often called LSP) is an important rule in object-oriented programming. It was first explained by Barbara Liskov in 1988. This principle is about "substitutability." It means that if you have a main type of object (like a class) and a special, more specific type of object that extends it (a subtype or subclass), you should be able to use the special object anywhere you would use the main object, and your program should still work correctly.
Think of it like this: if you have a program that expects a "Bird" object, and you give it a "Penguin" object (which is a type of Bird), the program should still run perfectly. The Penguin should behave like a Bird in all the ways the program expects. This rule helps make sure that when you build programs, different parts can work together smoothly without unexpected problems.
What the Principle Means
The Liskov substitution principle helps programmers design their code better. It says that if a type of object, let's call it S, is a subtype of another type, T, then you should be able to swap out any object of type T with an object of type S in your program. When you do this, the program should still work as expected and keep all its good qualities, like being correct.
This idea is stronger than just making sure the types match up. It's about making sure the objects behave correctly when they are swapped.
Rules for Subtypes
The Liskov substitution principle gives some important rules for how subtypes (like subclasses) should be created. These rules help make sure that the special objects can truly replace the main objects without causing issues:
- Input Types: If a method in the main type takes certain kinds of inputs, the same method in the subtype must be able to accept those same inputs, or even broader ones.
- Output Types: If a method in the main type gives back a certain kind of result, the same method in the subtype must give back that same kind of result, or a more specific kind.
- Exceptions: A method in the subtype should not throw new types of errors (called "exceptions") unless those errors are also types of errors that the main type's method could throw.
Besides these rules about inputs and outputs, there are also rules about how the objects behave:
- Starting Conditions (Preconditions): When you use a method in the subtype, you should not need more things to be true beforehand than you would for the main type. You can't make the requirements stricter.
- Ending Conditions (Postconditions): After a method in the subtype finishes, it must guarantee at least the same things (or more) that the main type's method would guarantee. You can't make the promises weaker.
- Keeping Things Consistent (Invariants): Certain facts about an object should always be true, no matter what methods are called. These "invariants" must stay true for the subtype as well.
- History Rule: This is a special rule. It means that the way an object changes over time (its "history") should be consistent. For example, if you have an "Immutable Point" (a point whose position never changes after it's created), you can't make a "Mutable Point" (a point whose position can change) a subtype of it. This is because a mutable point can change its state, which an immutable point cannot. The history of a mutable point would include changes, while the history of an immutable point would not.
Why LSP is Important
The Liskov substitution principle helps programmers create flexible and reliable software. By following these rules, they can build systems where different parts can be easily updated or replaced without breaking the whole program. This makes code easier to maintain, understand, and expand in the future. It's a key idea for building strong and dependable software.
See also
In Spanish: Principio de sustitución de Liskov para niños
