Part 1 here.
The Liskov Substitution Principle states:
“If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when o1 is substituted for o2 then S is a subtype of T.”
When using inheritance, a subclass should be able to be used wherever a super class is used, without altering program behaviour. If we refer back to the OCP, we know that classes should be open for extension but closed for modification. As I stated previously, when extending class behaviour it is important to keep in mind the LSP. Overriding a method is dangerous as you could unintentionally alter program behaviour. In order to prevent this, there are a few rules we can follow:
Wikipedia states:
Preconditions cannot be strengthened in a subtype. Postconditions cannot be weakened in a subtype. Invariants of the supertype must be preserved in a subtype. History constraint (the "history rule"). Objects are regarded as being modifiable only through their methods (encapsulation). Since subtypes may introduce methods that are not present in the supertype, the introduction of these methods may allow state changes in the subtype that are not permissible in the supertype. The history constraint prohibits this. The was the novel element introduced by Liskov and Wing. A violation of this constraint can be exemplified by defining a MutablePoint as a subtype of an ImmutablePoint. This is a violation of the history constraint, because in the history of the Immutable point, the state is always the same after creation, so it cannot include the history of a MutablePoint in general. Fields added to the subtype may however be safely modified because they are not observable through the supertype methods. One may derive a CircleWithFixedCenterButMutableRadius from ImmutablePoint without violating LSP. Perhaps one of the better examples I have come across regarding violating the LSP is this one on doodle project, using linked lists.
The Interface Segregation Principle states:
“Make fine grained interfaces that are client specific.” OR “Clients should not be forced to depend upon interfaces that they do not use”
It’s almost common place to see an object of Customer inherit ICustomer, but what benefit does it really give you? Abstraction you say? Maybe you will want to proxy the object later on to write your own lazy loading when you optimize the system? You know it’s good practise, so you do it.
Well, I don’t like that design. In fact, I cringe at the thought. I consider it an anti-pattern, the fat interface anti-pattern (it probably has another name, I don’t know). By doing this, we limit ourselves to getting the full benefit of code reuse, amongst other things. Interfaces should describe what functionality a class offers. You don’t see IDisposable implemented by a concrete class called Disposable, no, you see it adding functionality to an existing class, telling the world that the class has custom logic that needs to run when you dispose of that object.
You break down fat interfaces into more logically grouped contracts of functionality and then compose them to create a single object. Customer : IContainsAddress, ICanBuyStuff, IHaveOtherFunctionality etc etc. then you can pass customer to any method that accepts the above mentioned interfaces.
Finally,
The Dependency Inversion Principle states:
Depend on abstractions, not on concretions.
Chances are, you have heard the term inversion of control being thrown around. Well, IoC is a way to “invert” the flow of control within a system. Dependency injection is a specific form of IoC where you inject dependant modules into an object. That object depends on an abstraction (commonly an interface) to describe the intent of the object, however it does not know any more implementation details beyond this.
Dependency inversion is an architectural decision to decouple layers between a system, allowing you to build a more robust, maintainable, extendable and adaptable system with less effort and impact than you would encounter in a traditional, top down procedural style of architecture.
Subscribe