Lists are your friends

Sometimes I feel the real world has forgotten the concept of lists. I won’t mind if people start utilizing these simple yet elegant data structures more.



Conceptually, say you need to model an entity that has several pieces of information (values) associated with it. What do you? Do you attach them as individual properties on the entity or as single list property that includes them all? Some rule of thumbs to answer this can be found in the bellow table.

yesno
values length is small and fixedpropertylist
a value has semantic meaning on it’s ownpropertylist
a value has same nature as other valueslistproperty

For the sake of the example, say you work on a platform that sells books in different countries. You need to display this to the end user and you transmit this data in a JSON format.

Other examples would be payment methods, currencies, means of transportation.

The natural, but simplified, structure represented as JSON would be

1
2
3
4
5
6
7
8
9
{
"id": 1,
"title": "Cooking Foo Bar",
"pageNumber" : 321,
"availableCountryCodes": [
"US",
"CA",
]
}

and NOT

1
2
3
4
5
6
7
8
{
"id": 1,
"title": "Cooking Foo Bar",
"pageNumber": 321,
"US": true,
"CA": true,
"MX": false,
}

The “NOT” example is a manageable approach when you first start with only two or three countries. As humans we can reason about them because we can count them using just one hand. But let’s consult the above table.

Is the values length small and fixed? Small yes, but it varies from product to product, so go with the list. Further more, this allows you to support a new country by default.

Next, properties name should mean something. Take "US": true - the key is just a identifier, what does this refer to to? I could name it as availableInUS and then just iterate over the keys that start with a prefix but that just proves that what I really need is a list under a semantically meaningfully name.

Finally, the third point from the decisional table, do they have the same nature? All are countries thus they could be grouped together instead of being spread out.

When you are using a relational database management system you’d want to avoid adding/removing a column when you increase/decrease the set of countries you support, so better model it as a many-to-many relation. It makes non trivial querying a lot easier as well.



It’s true that some storing options, libraries or even the code that you are writing benefit from transforming a list to a Map/Dictionary, but I’d rather keep that scoped near those subsystems.

To be fair, one could fall in the other extreme where everything is a list, but I think the frequency of underutilized lists is way higher than over-utilizing them.



If the article stated the obvious for you, I’m glad. For the others, I hope it convinced you that lists can make your life easier.



Thumbnail image by unknown artist.