The Building Blocks of Architecture
Software is less like a snowflake, where every one is truly unique, and more like a LEGO set. We can combine the Legos in many configurations to make whatever shapes we need at the time, but the key building blocks are the same. However, these building blocks are more than simple algorithms and data structures; patterns are more than these building blocks or Legos themselves. They are closer to the molds that form the different Legos. They provide a way to ensure that any Legos made from the mold will work with each other, providing additional support and definition as more Legos are connected.
More specifically, the different parts of a software architecture solve problems that are not unique. The same problems keep surfacing in many different systems, regardless of the type of customer domain. Let's look at a specific example. Often in software we need to handle multiple objects that are dependent on the state of another object. For example, in an accounting system you may provide multiple views of the data, perhaps multiple spreadsheet views as well as graphical views. Whenever you change the data in one spreadsheet, the user would reasonably expect the other views to change (automatically, without selecting a refresh option).
Patterns, though, transcend a specific domain. For example, in an embedded system you may have a similar problem of multiple objects (such as monitors) watching a piece of hardware (through its software encapsulation/device driver) that has to react quickly when an interrupt such as low power occurs. A pattern can describe this situation and address how to proceed in a readily transferable manner. For example, this monitoring approach is described as the Observer Pattern [Gam, 95], summarized here:
Observer PatternIntent Define a one-to-many dependency between objects so that when one object changes state, all of its dependents are notified and updated automatically. Varies Varies the number of objects that depend on one another and how the dependent objects stay up-to-date. Structure Figure 2.1 illustrates the Observer Pattern structure. Figure 2.1. Observer Pattern Structure
Comments The Observer Pattern is also referred to as publisher-subscriber [Bus, 96] and is a major aspect in the document-view concept. The complexity in the Observer Pattern is often an implementation decision such as whether to use a push model (and send the data about the subject to the observer) or to use a pull model (and have the observer obtain the information it needs). Often a proxy pattern [Gam, 95] is used with the observer to allow remote observers to be used. If some of the clients are remote, you need to consider whether to use push or pull notification because of the perfomance implications of remote notifications and network overhead issues. |
