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.

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.

Dependency injection? How about using the service locator.

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's the wrong abstraction. A majority of daily code deals with data transformations and workflows and functions are the best fit for that.

The venerable master Qc Na was walking with his student, Anton. Hoping to prompt the master into a discussion, Anton said "Master, I have heard that objects are a very good thing - is this true?" Qc Na looked pityingly at his student and replied, "Foolish pupil - objects are merely a poor man's closures." Chastised, Anton took his leave from his master and returned to his cell, intent on studying closures. He carefully read the entire "Lambda: The Ultimate..." series of papers and its cousins, and implemented a small Scheme interpreter with a closure-based object system. He learned much, and looked forward to informing his master of his progress.

On his next walk with Qc Na, Anton attempted to impress his master by saying "Master, I have diligently studied the matter, and now understand that objects are truly a poor man's closures." Qc Na responded by hitting Anton with his stick, saying "When will you learn? Closures are a poor man's object." At that moment, Anton became enlightened.

OO works well in some cases. Procedural in some. Functional in some.

And a lot of it is how it fits the person. There are different ways of thinking, and a different way matches more naturally to an architecture choice.

Some of it fits the problem; sometimes performance is top priority, sometimes it isn't. Sometimes maintaining a consistent architecture for decades across a large team is important sometimes it isn't.

Sometimes it's the organization. We've recently switched to Domain Driven Design, I don't naturally tend to like it, but for how our organization and communication is structured, it helps get the business logic into code in a way that didn't exist as well before.

Learning about architecture and picking the right tool for the right job is important. OO might never be the right tool for you, but may have more use to someone else.

I explained Liskov substitution like this:

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.