Separate Operations From Data - Data-Oriented Programming v1.1 – Inside.java
Not surprisingly, data-oriented programming (DOP) has a strong focus on data. In fact, three of the four guiding principles of DOP v1.1, which we’re exploring in this series, advise how to best model that. In this article, we’ll examine the fourth principle, which concerns the methods that implement most of the domain logic. It advises to separate operations from data.
We’ll continue to use the example of a simple sales platform that sells books, furniture, and electronic devices, each of which is modeled by a simple record. They all implement the sealed interface Item, which declares no methods because there are none that the three subclasses share.
When exploring how to model data, I laid out which methods fit well on records and which less so. I basically excluded all methods that contain non-trivial domain logic or interact with types that don’t represent data - let’s call them operations. Operations turn an extensive but ultimately lifeless data representation into a living system with moving parts.
In data-oriented programming, operations should not be defined on records but on other classes. Adding an item to the shopping cart would neither be Item.addToCart(Cart) nor Cart.add(Item) because Item and Cart are data and therefore immutable. Instead, the ordering system Orders should take over this task, for example with Orders.add(Cart, Item), which returns a new Cart instance that reflects the operation’s outcome.
