Ever since I switched from Java and started programming in PHP and Python, both dynamic languages, I have had a debate with myself on whether or not to use arrays as business domain objects. I noticed the codebase I was working in passed arrays a lot in $params variables. In this post, I share, literally , the debates I had with myself regarding this issue in an easily digestible debate themed blog post!
Can Arrays be Used as Domain Objects?
I use arrays because, at the moment, I am currently using PHP in my work. But this can easily be translated to dictionaries in Python or wait what Maps in Java? From the pov of someone who used to program enterprise Java, it already sounds like bad design. Is it?
Arrays for Rapid Development
Using arrays can speed your development times. You don’t have to be in analysis paralysis thinking about too many things when designing your classes.
Counter-Retort: At least think about the future. It is not forward compatible.What if one day that domain object suddenly should exhibit some behaviour? It’s hard to change your codebase to accommodate that change. In PHP, one would have to use the -> notation to invoke getters or a magic method from the index notation that arrays use to access data. In Python it’s also the same. In Java…don’t get me started.
- Retort: There are work arounds to this, in Python, you can use a hybrid dict/object. In PHP, ArrayObject. In Java, I don’t know.
- Counter-Retort: Those features are cool but doing things that way leaves no room for validation of data as in the case of setters, and what if the getter had to do some processing before returning a value?
Arrays 0 Objects 1
Objects can be Ugly Sometimes
Imagine querying an object using an ORM when you need only some fields of that object, say a facebook account that contains so many attributes but where I only need the access token.
Counter-Retort: There is no harm in querying the whole object.
- Retort: Peformance?
- Counter-Retort: Do I smell premature optimization? Of course, there will be times when one only needs to iterate and display the data in an object and no behaviour will be invoked. During those times, the use of arrays is completely fine, provided your data access layer or orm can return array representations or object ones quite easily . If a behaviour is required by the service layer, then the object representation should be returned back to it by the dao. Run your tests after. Either way, it is still best to query the whole object for forward compatibility. You might need the other values one day.
This round is a draw.
Objects don’t do the job sometimes.
What if you wanted to display a table or information that is a relationship? For example, a purchase transaction for a book. In an RDBMS, this is usually a relationships table with foreign keys. In the book transaction example, there will be a separate table for book and customer and another one for transaction which brings both of them together. Do I have to make a separate object for that? Can’t I just shove these values to an array?
- Counter-Retort: I guess if you just wanted to display information, then arrays are okay, again, provided that your data access layer/orm makes it easy to query for object or array but there will be cases when, for example, that object needs to exhibit a behaviour, then it has to be callable.
This round is also a draw.
Summing Up
- Arrays are okay as long as it will be only used for displaying. It is much easier to iterate over arrays than objects.
- When an object has to exhibit behaviour, query for object.
{{ parent.title || parent.header.title}}
{{ parent.tldr }}
{{ parent.linkDescription }}
{{ parent.urlSource.name }}