Or How to Create Beautiful Abbreviations This is a third post on principles — check out if you missed it. Here I start with a short intro on how this concept was forming, and demonstrate a descriptive example (no Square and Rectangle, I promise!). SOLID the Open closed principle , 1986 Bertrand Meyer Bertrand Meyer first introduced the concept of contract and implemented it in his language . Contract is identified by , and . Here is a nice summary from : Eiffel preconditions invariants postconditions Wikipedia 1. [A routine can] Expect a certain condition to be guaranteed on entry by any client module that calls it: the routine’s precondition — an obligation for the client, and a benefit for the supplier (the routine itself), as it frees it from having to handle cases outside of the precondition.2. Guarantee a certain property on exit: the routine’s postcondition — an obligation for the supplier, and obviously a benefit (the main benefit of calling the routine) for the client.3. Maintain a certain property, assumed on entry and guaranteed on exit: the . class invariant There is only one language I’m aware of where contract is a built-in concept — it’s Eiffel itself. In other languages contract can be enforced by method’s signature: type of an arguments, type of return value and an exception that can be thrown. But since it’s hardly feasible to invent a type-system that can be used to enforce all existing business-rules, this approach is quite limited. , 1994 Barbara Liskov The way Barbara Liskov posed her principle represents a concept of , or subtype polymorphism. This type of polymorphism is the most common in Object-oriented programming and is usually referred to as simply “polymorphism”. Liskov formalized the Meyer’s approach and it looks way more : subtyping academically Let φ(x) be a property provable about objects x of type T. Then φ(y) should be true for objects y of type S where S is a subtype of T. The repeats pretty much everything that Bertrand Meyer already has said, but it relies totally on a type-system: human-readable version 1. Preconditions cannot be strengthened in a subtype.2. Postconditions cannot be weakened in a subtype.3. Invariants of the supertype must be preserved in a subtype. , 1996 Robert Martin Robert Martin made the definition sound more smoothly and concisely: Functions that use pointers of references to base classes must be able to use objects of derived classes without knowing it. However, he hasn’t introduced anything new. Violation of Liskov Substitution Principle I often find that in order to comprehend some principle it’s important to realize when it’s violated. That’s what I want to do now. What does the violation of this principle mean? It implies that an object doesn’t fulfill the contract imposed by an abstraction expressed with an interface. Or, in other words, it means that you . identified your abstractions wrong Consider the following example: Account{ withdraw(Money $money);} interface /*** Withdraw $money amount from this account.** @param Money $money* @return mixed*/ public function DefaultAccount Account{ ; class implements private $balance **public function** withdraw(Money $money) { **if** (!$this->enoughMoney($money)) { **return**; } $this->**balance**\->subtract($money); } } Is this a violation of LSP? Yes, since Account’s contract tells that an account would be withdrawn, but this is not always the case. So what should I do in order to fix it? I just modify the contract: Account{ withdraw(Money $money);} interface /*** Withdraw $money amount from this account if its balance is enough.* Otherwise do nothing.** @param Money $money* @return mixed*/ public function Voilà, now the contract is satisfied. This subtle violation often imposes client with the ability to tell the difference between concrete objects employed. For example, given the first Account’s contract, it could look like the following: Client{ go(Account $account, Money $money){ ($account DefaultAccount && !$account->hasEnoughMoney($money)) { ;} class public function if instanceof return $account->withdraw($money); } } And this automatically violates . Open closed principle This point also addresses a misconception that I encounter quite often about LSP violation. It goes like “if a parent’s behavior changed in a child, than it violates LSP”. It doesn’t — as long as a child doesn’t violate its parent’s contract. Liskov Substitution Principle in SOLID My problem with this abbreviation is that if “polymorphism” is present there, why “encapsulation” and “composability” aren’t? Those are in no way less important. Probably it’s because it’s hard to come up with beautiful abbreviations using “e” and “c”? I bet it is. Wrapping it up Don’t get me wrong, I like SOLID and the approaches it promotes. But it’s just a shape of deeper principles lying in its foundation. The examples above made it clear what this principle is striving for: it’s . In other words, don’t make your clients care what concrete class is in use. Noble goal, but how to achieve it? First, start with — domain. Second, express your contract in plain English in a method signature. loose coupling decomposing your problem space
