Solid in Java: Liskov Substitution Principle

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.

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.