Thursday, September 17, 2009

Layers

Layers is arguably the most common architectural pattern and most of the software I have been exposed too have been organized more or less using it. Broadly speaking it is a pretty obvious concept, but the pattern does contain pretty interesting discussions on tradeoffs. It highlights the most central set of conflicting forces in considering this pattern which are the tension between clear separation into multiple layers (modularity) and efficiency. Efficiency concerns come from the fact that multiple layouts and enforced interfaces usually carries an overhead. As one version of the controller part of the MVC song goes: "I wish I had a dime for every single time, I passed on a String". In some types of software such as driver and system software this might be an important tradeoff.

One such case I have experienced was implementing an old industry standard API on a modern and novel piece of hardware. In this case the software layers had to do a lot of costly reshuffling and tricks in order to conform to the specified API interface. As such the required layering came with a big performance hit. However, in most types of software such as most application software this is not a big problem and one are free to select the best abstraction without worrying too much about the efficiency of them.

The chapter mentioned defined interface objects to layers. I guess that they by this mean facade classes such as the one they used as the interface to their model in the making memories system. Furthermore I found the comment on keeping the lower layers as slim as possible to be very true. It also follows the Unix adage of providing features and not policy. Another interesting point was their observation that one should avoid defining components first and them put them into layers. They argue that this will likely lead to a system where layers doesn't really capture the inherent ordering principles of the abstractions. The layer organization will therefore not be intuitive and is unlikely to be respected by maintainers in the future who will take shortcuts and violate the systems conceptual integrity.

No comments:

Post a Comment