One theme that often comes up when talking about abstraction is that of boilerplate code. There are two points worth considering here.
First, with most boilerplate code, one should strive to hide as much of the details as possible, so as to remove visual clutter and let the reader focus on the meat of what’s being done. How far you can take this will depend on how extensible the language you use is. The continuum of available options ranges from simple functions through decorators/annotations, all the way to completely new language constructs.
EXAMPLE using synchronized
Second, one needs to remember that there is an inverse relationship between how general the abstraction is and how much adapter code is necessary to invoke it. A very specific abstraction may be callable by just its name, with no parameters, but it will only serve a limited number of use cases. A more generic abstraction would allow you to get rid of a wider range of boilerplate code, but you are likely to incur the price of having to write adapter code. At some extreme, you can imagine an all-powerful abstraction that in a single call does everything you want a program to do. The price you’d pay for such an abstraction is its necessarily complex parametrization — there’s no running away from specifying the work that needs to be done, so you’ll have to specify it through parameters.
Comments
Post a Comment