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.

> A majority of daily code deals with data transformations

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.

"Object Oriented design is the Roman Numerals of Computing" - Rob Pike

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.

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].

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.

=== [1] https://youtu.be/8ZJ8BVlDIQ4?t=1762

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.