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.
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.
I think you confuse _your_ job with what everyone else does.
Do some people mostly work with data transformations? yes they do.
But do some people mostly work with system programming? yes they do.
But do some people mostly work with creating user interfaces? yes they do.
But do some people mostly work with network programming? yes they do.
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.
A subclass should behave in a way that it never cause problems when it is used instead of the base class.
In concrete terms:
* No new exceptions are allowed to be thrown, unless they are subtypes of the exception thrown by the base class
* Preconditions cannot be strengthend by the subtype
* Postconditions cannot be weakened by the subtype
For me it is really the focus of using inheritance only if you want substitutability. Otherwise go with composition.
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.
