Abstraction in Elm: Wrappers and Generics for Everything
Table of Contents
- Introduction
- One Expression to Rule Them All
- Introduce Comments
- Introduce Local Functions
- Utility-Based Modularization
- Domain-Based Modularization
- Wrappers and Generics for Everything
- Conclusion
Code
Let’s suppose that I don’t care about how hard others have to work to find the details of my system’s behavior. Let’s say that clarifying my intent through complex structure is my highest goal. Let’s say I decide to go for extreme abstraction. I could do something like this:
Discussion
This code is now thoroughly more abstract than it needs to be. ColorMode might become worthwhile some day if we get to a point where we need four or five color values associated with each RunStatus, but this seems highly unlikely. Also, is there really a lot of value in abstracting the transition out of each part of oscillate? This has “solved” a duplication issue of only two elements that were unlikely to change (because they are tied to an external library). And making Model.RunStatus’s setters more generic has improved clarity of intent only marginally while introducing a new parameter to be parsed and understood by readers.
A little abstraction applied to concrete code initially yielded enormous returns in the form of duplication removal and readability. However, this code’s overly complex nature actively degrades its readability.
Analysis
Pros
- We have given names and partitions to all parts of the system in which even the minutest intent was present. Why we have the code that we do (our intent) is utterly clear.
Cons
- Learning simple concepts within the system requires learning about an enormous number of relationships between partitioned chunks of code. Some of these partitions have nothing to do with either utility or domain concerns.
- Discovering implementation details (the what) is time-consuming and involves mental contortions in order to hold the structure of the system in mind. This is necessary for even the simplest of operations.
- The relationships between various parts of the system, which initially started to improve as we added abstraction, have now degraded. This heavily abstract system is as unclear as the heavily concrete system in terms of how the parts of the system relate to one another.
Continue to Abstraction in Elm: Conclusion.
