Solid in Java: Liskov Substitution Principle

Around 2013 I wasted a whole year trying to understand OOP. C2Wiki anyone? OOP multiplies delivery times by 50 with pointless data bureaucracy and people wonder why 80% of programming projects are never delivered.<p>If you are forced to use OOP, just use one method for every class. This is the function object pattern and you get Liskov Substitution and all the great SOLID principles for free.<p>Dependency injection? How about using the service locator.<p>I think objects make sense as data containers, where data is centralized within the app and you just have all the data access methods in one place but for everyday design ... it&#x27;s the wrong abstraction. A majority of daily code deals with data transformations and workflows and functions are the best fit for that.

Well it would have been nice if he stated his interpretation of the Liskov Substitution Principle. The way i understood it best was here [1].<p>A subclass should behave in a way that it never cause problems when it is used instead of the base class.<p>In concrete terms:<p>* No new exceptions are allowed to be thrown, unless they are subtypes of the exception thrown by the base class<p>* Preconditions cannot be strengthend by the subtype<p>* Postconditions cannot be weakened by the subtype<p>For me it is really the focus of using inheritance only if you want substitutability. Otherwise go with composition.<p>=== [1] <a href="https:&#x2F;&#x2F;youtu.be&#x2F;8ZJ8BVlDIQ4?t=1762" rel="nofollow">https:&#x2F;&#x2F;youtu.be&#x2F;8ZJ8BVlDIQ4?t=1762</a>

I explained Liskov substitution like this:<p>Nicholas Cage is an actor, Tom Hanks is an actor however you can’t substitute a Nic Cage performance for a Tom Hanks performance. Therefore Nic Cage is a Liskov Substitution Violation.