Comment by Ciantic | Hacker News Reader

Comment by Ciantic | Hacker News Reader

Everytime I hear about Data-Driven/Oriented Design I remember a paper from OOP course I had to read in University, it used Data-Driven Design as an example how to not to do things.

The paper in question is this from 1989: https://dl.acm.org/doi/pdf/10.1145/74877.74885

It highlights that:

"Even though the goal of data-driven design is to encapsulate data and algorithms, it inherently violates that encapsulation by making the structure of an object part of the definition of the object. This in turn leads to the definition of operations that reflect that structure (because they were designed with the structure in mind). Attempts to change the structure of an object transparently are destined to fail because other classes rely on that structure. This is the antithesis of encapsulation."

Then goes to show that Responsibility-Driven Design has better approach.

What we mean with Data-Driven Design have come a long way though, and isn't comparable to those days.

I find it a bit amusing that Data-Driven Design used to be an insult of sorts, like you didn't know how to do things OOP the right way.

You do realize that DoD has nothing to do with data-driven, right?

Data oriented design is about structure the data in regard of how it is processed and the hardware. This is opposite of object oriented design which models the data around your mental model.

For example in DoD you could design a map with keys in one array together and one array of values. This would make it much faster to iterate over keys while searching because of cache memory.

While in object oriented you would store an array of pairs.

Both approaches can use data-driven.

Edit: would -> could

There are also multiple definitions of "data-driven" floating around depending on qualifier/context. An OLAP RDBMS, for example, will certainly be written in a data-oriented way, and also have almost fully data-driven behavior, but will certainly not have data-driven (in the sense of that paper) design.

While I agree with your point, the map example is not entirely well represented in your comment. The idea is not to just store keys and values in separate arrays, the idea is to look at your use case and model your data after the transformation you need. So if you have a case where storing keys and values as pairs because of your access pattern, then do that, if you have a case where you do a lot of searches through keys, then store them in separate arrays.

The point of DoD is to look at the data you have and the data you need it transformed into and then structure your data after.

The example given as "data driven design" in this paper neither resembles modern data driven programming nor data oriented design.

I don't quite understand why the authors thought of this as a good example of "data driven design".

I know that functions in a data driven program tend to be very generic so the conclusion you cite is very much a mismatch from my experience.

Reply on news.ycombinator.com