Think different about data model #12
In Data oriented design data is King, behaviour is servant.
After the presentation I shortly spoke with Jens, who asked me if there are similarities in data oriented and protocol oriented programming. Protocol oriented programming was introduced by Apple at this WWDC and is a hot topic in Swift community.
I felt like there are similarities, but even more differences. However I was not ready to spontaneously elaborate on those. Now, I am!
The concepts seems to be similar from the first glance, because they both incorporate the composition principal.
If an object implements a protocol, we don’t have to know what exactly it is. We can downcast it to it’s protocol.
However as I also mentioned in Article 6, object are slaves of there own heritage. When we create an object, it has to be of a certain class. We have to start with something concrete and complex before we use it in a simple way.
On contrary with data oriented approach, we create an entity which is just an empty bag. We can add components to it, shaping it to become something concrete and complex. We can also reshape it completely at runtime. This is very close to the concept called duck typing.
In the talk at swift.berlin I described a conference App I was writing. So I would like to use it now as an example to make my point clear.
We can say that there are following components:
To represent a talk we can create an entity which hold title and speakers name. At runtime, user might rate the talk. We will add a rating component to it. This way we transformed a talk into a rated talk.
This kind of “magic” is impossible with protocol oriented approach. You would have to create a new instance of type RatedTalk and copy the data from Talk instance into RatedTalk instance.