Use data structures for your business logic
A few months ago I was reviewing a PR that handled relationships between entities. As I was working through the code I started to notice a pattern that made me go back to the original feature ticket for a quick review of the acceptance criteria. As I suspected there was a list of around 10 "if this then that" scenarios detailed, all of which manifested as conditions in the code. Grabbing a pen and paper I started to draw out the criteria and as I suspected all the scenarios were captured by relationships and operations for a Tree.
Going back with this information I paired with the team on an update to the PR where we reduced the amount of conditions tied directly to the business domain, and refactored names so that future maintainers could interact with the code understanding a tree, but maybe not understanding all the business logic around the entities.
in case it's helpful the C5 project has some collections not found in the .NET Standard library for interacting with Trees. In general an interesting project I'm glad I learned about.
A similar opportunity emerged on the same project when we needed to make
sure a value was unique over a series of operations. In this scenario while
working on a collection of objects we were able to use a HashSet
to exit if Add
false instead of setting up a
LINQ query. This
resulted in less nesting, less code, and a simplified condition.
The reason I am writing this is that we should be using data structures
to represent the business logic of our applications. This seems obvious,
but too often I have seen implementations brute force conditions leaving
data structures as an optimization, or a concern for "technical" projects.
While we can use a series of
if conditions and predicates to meet requirements
in a crude way, using data structures provides an abstraction that can elevate
terse business logic to a construct future maintainers can derive extra