OOP vs DOP: Rethinking Design, Complexity, and Trade-offs

On Wednesday, I attended an 𝗢𝗢𝗣 𝘃𝘀 𝗗𝗢𝗣 discussion that challenged the way I think about software design, complexity, and trade-offs.

𝗤𝘂𝗶𝗰𝗸 𝗴𝗿𝗼𝘂𝗻𝗱𝗶𝗻𝗴 𝗯𝗲𝗳𝗼𝗿𝗲 𝗱𝗶𝘃𝗶𝗻𝗴 𝗶𝗻

𝗢𝗯𝗷𝗲𝗰𝘁-𝗢𝗿𝗶𝗲𝗻𝘁𝗲𝗱 𝗣𝗿𝗼𝗴𝗿𝗮𝗺𝗺𝗶𝗻𝗴 (𝗢𝗢𝗣) organizes software around objects that bundle data and behavior together. It relies on abstraction, encapsulation, inheritance, and polymorphism.

𝗗𝗮𝘁𝗮-𝗢𝗿𝗶𝗲𝗻𝘁𝗲𝗱 𝗣𝗿𝗼𝗴𝗿𝗮𝗺𝗺𝗶𝗻𝗴 (𝗗𝗢𝗣) focuses on modeling data first and driving behavior from that data. It often favors simplicity, immutability, and pattern matching over deep object hierarchies.

𝗟𝗲𝘁 𝗺𝗲 𝘀𝘁𝗮𝗿𝘁 𝘄𝗶𝘁𝗵 𝘁𝗵𝗲 𝘀𝘁𝗼𝗿𝘆𝘁𝗲𝗹𝗹𝗶𝗻𝗴

The way Dr. Venkat Subramaniam teaches is refreshing.

A three-hour workshop felt like a thirty-minute conversation.

No slides.
Just live typing in Notepad, thinking out loud, and building ideas step by step.

As a visual learner, this style really worked for me. It was easy to follow and very different from the usual conference-style presentations.

𝗡𝗼𝘄 𝘁𝗼 𝘁𝗵𝗲 𝗰𝗼𝗻𝘁𝗲𝗻𝘁

Java has been centered around Object-Oriented Programming for more than thirty years, and as a community, we are deeply attached to its principles. But one question set the tone for the entire session:

👉 𝗜𝗳 𝘄𝗲 𝗳𝗼𝗹𝗹𝗼𝘄 𝗱𝗲𝘀𝗶𝗴𝗻 𝗽𝗿𝗶𝗻𝗰𝗶𝗽𝗹𝗲𝘀 𝗯𝗹𝗶𝗻𝗱𝗹𝘆, 𝗮𝗻𝗱 𝘁𝗵𝗲 𝗱𝗲𝘀𝗶𝗴𝗻 𝗶𝘀 𝘀𝘁𝗶𝗹𝗹 𝗯𝗮𝗱, 𝗮𝗿𝗲 𝘄𝗲 𝗿𝗲𝗮𝗹𝗹𝘆 𝘀𝗲𝗿𝘃𝗶𝗻𝗴 𝘁𝗵𝗲 𝗽𝘂𝗿𝗽𝗼𝘀𝗲?

That’s where the discussion got interesting.

𝗥𝗲𝘃𝗶𝘀𝗶𝘁𝗶𝗻𝗴 𝘁𝗵𝗲 𝗳𝗼𝘂𝗿 𝗽𝗶𝗹𝗹𝗮𝗿𝘀 𝗼𝗳 𝗢𝗢𝗣

𝗔𝗯𝘀𝘁𝗿𝗮𝗰𝘁𝗶𝗼𝗻
Changing behavior without directly changing code, and how humans stay sane when dealing with complexity by focusing on what instead of how.

𝗘𝗻𝗰𝗮𝗽𝘀𝘂𝗹𝗮𝘁𝗶𝗼𝗻
Implementation hiding, or the separation of what from how. This applies at many levels, from functions and files to classes, components, subsystems, and entire systems.

𝗜𝗻𝗵𝗲𝗿𝗶𝘁𝗮𝗻𝗰𝗲
Often one of the weakest links of OOP when overused. Instead of defaulting to inheritance, the focus shifted to design by contract and design by capability.

𝗣𝗼𝗹𝘆𝗺𝗼𝗿𝗽𝗵𝗶𝘀𝗺
Behavior chosen at runtime, not compile time. It often appears with inheritance, but it does not require it and can also be achieved through interfaces, composition, or pattern matching.

This framing made the principles feel less like rigid rules and more like design tools with real trade-offs.

𝗗𝗲𝘀𝗶𝗴𝗻 𝗽𝗿𝗶𝗻𝗰𝗶𝗽𝗹𝗲𝘀 𝗶𝗻 𝗮𝗰𝘁𝗶𝗼𝗻

We explored the Open-Closed Principle and Dependency Inversion Principle.

A simple design evolved from:

OrderProcess -> CreditCard

to:

OrderProcess -> PaymentMethod <- CreditCard

Here, OrderProcess depends only on the abstraction, while CreditCard implements that abstraction, keeping high-level logic decoupled from concrete implementations.

𝗕𝘂𝘁 𝘁𝗵𝗲𝗻 𝗰𝗮𝗺𝗲 𝘁𝗵𝗲 𝗰𝗼𝘀𝘁

DRY was violated
Parallel class hierarchies appeared
Code size increased
Complexity grew quickly
Runtime errors became easier to introduce
Exception handling became painful

At some point, it felt like we were managing complexity by naming it.

That led to an important question:

When does the cost of complexity outweigh the benefits?

𝗟𝗼𝗼𝗸𝗶𝗻𝗴 𝗮𝘁 𝗗𝗢𝗣

With DOP, the Open-Closed Principle is violated, and Dependency Inversion is not used.

But in return:

Much less code
No parallel hierarchies
DRY preserved
Simpler logic
Easier exception handling
Compile-time errors when new types are introduced

The contrast was clear.

OOP relies on polymorphism.
DOP relies on pattern matching.

𝗠𝗼𝗱𝗲𝗿𝗻 𝗝𝗮𝘃𝗮 𝗳𝗲𝗮𝘁𝘂𝗿𝗲𝘀

Records encourage immutability.
Sealed classes give compile-time guarantees by defining a closed set of allowed subtypes.
Switch becomes a powerful pattern-matching tool, not just a control-flow tool.

𝗠𝘆 𝗯𝗶𝗴𝗴𝗲𝘀𝘁 𝘁𝗮𝗸𝗲𝗮𝘄𝗮𝘆

Both in life and in programming, trade-offs are unavoidable.

I felt this personally. To attend this session, I had to choose between a Toastmasters meeting and the JavaMUG meetup. I could not be in two places at the same time.

Another insight that really stayed with me was Dr. Venkat’s perspective beyond any single language. He works with more than 15 programming languages, and his students often share that thinking beyond a fixed-language mindset helps them solve problems more effectively.

Focusing on thinking, not just syntax, was a powerful reminder.

No paradigm is perfect. What matters most is knowing when and why to use each one.

𝗖𝘂𝗿𝗶𝗼𝘂𝘀 𝘁𝗼 𝗵𝗲𝗮𝗿 𝘆𝗼𝘂𝗿 𝘁𝗵𝗼𝘂𝗴𝗵𝘁𝘀
Are you experimenting with DOP in Java yet, or are you still mostly in the OOP world?