20.11. Shims: Coda

I hope you're convinced of the utility and power of shims, and I encourage you to incorporate them in your work and take advantage of the low-cost and easily comprehensible generalization that they afford. But before any of the early adopters among you go away and start making everything use shims for everything, I'd like to make a note of caution. As with anything else in software engineering (and, waxing philosophical, in life, too), they are not a panacea, and they can be used to excess. They are not intended to be the prime mechanism of object manipulation. Notwithstanding the practical issues with respect to namespaces, if every second line in your code uses a shim, you've pretty much left the object-oriented world behind^[18] and started a new realm of attribute-based, almost declarative, programming. Too many shims can make your code virtually unreadable.

^[18] Of course, some would say that's not a bad thing.

We've seen that there is a downside to using conversion shims, or any composite shim comprising the conversion shim concept, wherein the return values can only be used within the lifetime of the expression containing the shim. A consequence of this is that one may be required to make multiple shim calls within a function or, where possible, restructure the function to only require one call to the shim. These issues are eminently surmountable in practice, but nonetheless require a level of cognizance of the particular shim concept that one is using, in much the same way that one must be mindful of the particular iterator concept when using a given STL sequence and its iterators.

To my mind, shims are, when used correctly, a powerful adjunct to "normal" C++ programming, and represent an excellent addition to the imperfect practitioner's tool kit.