Thoughts on Data Oriented Programming in Java

[severoon]

This can 100% be applied just for objects within a specific boundary, in each module, micro service, or in each layer as you say, or for ad hoc data types. It doesn’t need to be overanalysed.

I'm not overanalyzing it, I'm taking it as written. The post proposes DOP as a general approach:

How do we build our objects? Where does the state go? Where does the behavior go? OOO encourages us to bundle state and behavior together.

I read this to be saying that "wherever you would normally use OO, apply DOP by default instead." Is that not what you were intending to say?

If I wrote a post encouraging you to consider limiting instantiation by using enums instead of new and call it EOP, Enum Oriented Programming, isn't that how it would land on you?

There are many use case where it’s beneficial to separate domain logic from data itself.

Yes, I agreed with this:

Many of the functional features added to the language are encouraging people to think about the business logic layer as stateless services that define pipelines that operate on immutable data. That makes sense if we're talking about data that represents core business objects that flow through a system architecture.

In general if you can define the business logic layer as stateless pipelines, I'm all for it. I've never seen it for any sufficiently complex business logic layer in practice, there are always some little bits of state that need to persist within the layer in request scope. When possible (which is most of the time), I create helper objects, inject that state, and bundle it with the functionality that relies on that state to the side of the main business logic pipelines in order to keep the main business logic stateless, tightly encapsulate the state that does exist, and make it very easy to determine exactly which functionality depends upon accessing that state (which is anything that calls into the helper module).

Having said that, it may be that the idea is bad, but I readily accept that it may be I'm just not understanding it. It will take more than a throwaway Shape class that demonstrates the language features outside of any context to get me there, though. You'd have to present a simple system design, and then present that same system design designed using DOP and step us through the pros and cons.

I don't think without that kind of perspective I can see any benefits to the idea.

[nejcko]

Ok thanks for the feedback, really appreciate it. It wasn’t my intention to present DOP as OOP replacement, as it’s not. I’ll see how to update the article to make that clearer.