Patterns: Bringing Order to Software

If the Internet with its hundreds of heterogeneous software programs and computing platforms makes your head spin, then a quick survey of object-oriented programs will likely put you over the edge. Consider the number of ways that a simple problem, such as notifying interested parties of a change to an object's state, are solved with a platform such as Java 2 Standard Edition. Some developers may use an intermediate file to track changes, with interested parties reading the file to find out when and how an object changed. Other developers may construct a point-to-point notification system, or even a set of one-to-many Publish/Subscribe patterns. Some developers may have one type of naming convention for the adding and removing of listeners; other developers may not have any naming convention for the same operations.

Without a common way to solve the problem of notifying interested parties of a change to an object's state, everyone has a license to invent their own mechanism. This reinvention does not come free either; a robust notification mechanism can take days or weeks to perfect.

Patterns , simply, are a mechanism to document and educate others on problems that often occur when building software. You can limit patterns to your own software group , expand them to include your customers, or publish them to help the general software community.

Understanding Pattern Usage in the Computer Industry

Patterns exploded on the software scene after the 1995 publication of Design Patterns: Elements of Reusable Object-Oriented Software , the groundbreaking book from the "Gang of Four" (Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides).

Note  

Developers refer to this book as the GoF book; we will do the same throughout the text.

At this stage in software history, patterns are so pervasive that it is difficult to find software professionals without some knowledge of patterns, the most common being the 23 patterns discussed in the GoF book. Since the publication of the GoF book, patterns have emerged in dozens of texts and hundreds and thousands of Internet sites. The patterns range from the trivial idioms that apply to a particular language to the complex structure of a business application. Not only do patterns range from the trivial to the complex, but patterns also apply to situational human scenarios in the process of software development in addition to the more traditional mechanical patterns.

Software patterns that apply to your own software group include the rules and solutions for building applications unique to your company. These rules provide consistency in all of the efforts your software group embarks on, provided your architects , designers, and developers read the patterns. This model fits a traditional closed development lab that produces packaged software, but what if other software groups extend your software? In this case, it is useful to expose your patterns to those who will have to understand the software you build. By publishing to the extended community, you are able to aid your customers in understanding your design and implementation, while also ensuring that they maintain consistency in the designs for extensions and customizations.

The final step of publishing software patterns is what this book accomplishes. A book about software patterns helps you learn about patterns, software that uses patterns, and ways you could leverage the patterns in your own software.

Applying Software Patterns

Patterns apply to any portion of the software cycle. As shown in Figure 1-1, a typical software process goes through many stages (all of which are iterative in nature). Processes usually involve gathering requirements, creating the architecture, designing the software, and implementing it. The length of the individual steps, how the microtasks blend, and the artifacts from each step vary widely in practice; however, whether each step is implicit or explicit, the step occurs in one way or another.

Figure 1-1: A typical software cycle

Different problems and challenges exist in each step of the software cycle. As you encounter problems and challenges along the way, there is a 90 percent chance that someone else has encountered the same problem. During the requirements-gathering process, it is common that architects and the product marketing area have difficulties gathering proper requirements and formulating them into reasonable architectural requirements. In this case, you would look for patterns for requirements gathering.

During architecture, groups of requirements and business drivers generate use-cases and system structures. Often, given a requirement such as "The user - interface for the product shall integrate with other applications via portal standards" leads to an off-the-shelf system structuring to ensure user-interface integration with a portal. At a higher level yet, business requirements often lead directly to system structures and decision points. For example, knowing that becoming part of an integrated value chain will drive revenue for your company will drive a decision to go with Web Services to open up your own application.

Once in a design phase, patterns become more pervasive and formal. Thousands of software design patterns document the common problems encountered by software designers and generic solutions for those problems. For example, an architect may give a system structure that identifies a point in the system where an object change drives listeners to make changes in their own state, or the change kicks off a business process. In these cases, a designer can look and determine that the Publish/Subscribe or the Observer pattern can fulfill the requirements and constraints an architect put on the design. Once identification of patterns is complete, the generic structure given in a pattern drives the design of the particular system structure.

After design, programmers must develop the code that implements the design. Programmers are bound to a computer platform and language that typically do not bind the designer. Idioms are best practices for implementing a design in a specific language or platform.