Software Archicture: Layers of Abstraction (SALoA)

A.E.Veltstra 
2020-03-30 
  
A budding software engineer inquired about when to introduce a layer 
of abstraction into one's software architecture. 
  
My answer included that I introduce a new layer when the mental 
paradigm of a tool does not fit with that of my software. 
  
Say what?  
  
See this example, based on my own real-life experience:
  
Recently I wrapped Microsoft's JDBC for MS SQLServer in an abstraction 
layer. Well, only the parts that I needed. Their module is great and 
does its job very well. But its architecture is based on Java's 
insistence that there must be checked exceptions everywhere. While 
these have their place, handling them makes for tons of boilerplate 
code that obscures what my processes actually try to accomplish.

See, when your functions force the consumer to catch and handle 
checked exceptions, the java language forces the consumer to write 
those handlers in the code source. And when that code source uses 
lambda functions, those lambda functions require their own exception 
handling. It's exception inception: excessive, and hard to grasp when 
reading source code.
  
To reduce that problem, my abstraction layer wraps around the JDBC 
functions I need most, and provides exception handling and logging. 
That way the call sites can remain cleaner, making them easier to 
read, with less opportunity for coding errors.
  
Layers of abstraction hide complexity. Complexity is introduced with 
outside dependencies as well as one's self-built architecture. The 
more dependencies, the higher the overal complexity, and the more 
effort it takes you later and those who follow in your footsteps to 
understand what your software is supposed to do. 
  
Martin Fowler raged about this a few years ago and came up with the 
concept of Clean Code. You should look it up. One of the tennets is to 
gradually have your source code readers step deeper and deeper into 
the pits of darkness. Start off light, and let them descend only when 
they have a need. 
  
I like that concept. And thus I wrap complexities in abstractions that 
are easy to read. 
  
And when I revisit my own source code a few months later, and realize 
I still can't grok what I wrote, then it's time to refactor.
  
Happy coding!