Patterns,Frameworks, Specifications, Conventions & Configuration

Featured image

This post is all about introducing the terms above and talking about their place in architecture. There must be some pretty tough girders at the bottom of the Empire States Building! They have to bear the entire weight of over a hundred stories. The structural engineers who designed this building should have taken into account all kinds of forces and designed them accordingly. But how about a one storeyed structure? Do you think the structural engineer must be as scrupulous in designing this structure too? Of course he has to be! Whether it is a hundred storied structure or a one story structure, the engineer has to make sure that the girders, holding the structure, are capable of withstanding the forces that would be encountered. But if one single storied structure has been meticulously designed, do you think it makes sense to expend the same amount of effort for designing similar structures? Yes, if the architect never learns from his previous work. All these structures are more or less bearing the same kind of weight. Hence it makes sense to not replicate this effort. So what happens? Any engineer who undertakes the design of any building, that structurally resembles a predecessor, would end up replicating the structural drawings of its predecessor. Thus the “copy and paste” technology handles the engineer’s requirements very well. But before the copy and paste can happen, the commonality of the design between the two buildings must be recognized. This is what we call a “Design Pattern”. This design problem (i.e. the structural specification of the building) and its solution (the outcome of the design process) would get cataloged as a general idiom or a design pattern in the industry. Good architects and engineers would be taught to recognize these patterns and apply them as needed. Some of these idioms are so standard that they have even been cataloged as part of a “standard”. For instance, every Indian civil engineer would have to adhere to the recommendations of ISI - Indian Standards Institute. These recommendations are nothing but a catalog of best practices. In programming, we are similarly exposed to some design patterns that have become standard idioms in our vocabulary. Some of them have become so integrated with our way of thinking that we don’t even consider them as design patterns. Hence multi tier architecture, Model View Controller pattern, Asynchronous messaging etc. have become standard design practices. In specific projects these get documented as specifications that the engineering team has to adhere to. For instance a specification may stipulate that all user interaction logic must be constrained within the controller class. As we evolve in sophistication, we realize that it is is best to be preemptive than be stipulating i.e. it is better to constrain the design to comply with the best practices beforehand. Hence frameworks are the best enforcers of design patterns.

Design of frameworks

So how do we channelize an application to comply to the design patterns? There are various strategies to accomplish this. One or the other of these would form salient features of most frameworks:

Role of configuration with frameworks

Frameworks have classes that are super generic. They know to process different types of user requests and tend to provide hooks for accomplishing application specific behavior. Hence the necessary information about when to call the hooks, needs to be furnished to the framework. This is typically achieved using configuration. For instance, a J2EE server needs the web.xml file. This file tells the server the URL for which a certain hook (ex: servlet or servlet filter) needs to be invoked. Hence it is common place to see frameworks associated with a bunch of configuration files typically in xml.

Problems with Configuration

Configuration provides a flexible way of incorporating extensible functionality. But configurations tend to suffer from several problems:

Solution With Conventions

The latest frameworks have used conventions to solve some of the configuration problems. Conventions have been a part of the framework designer’s arsenal for quite sometime now but it is only recently that its role has been recognized. Here are some situations where convention has been successful.