Transition

The point of iterative development is to do the whole development process regularly so that the development team gets used to delivering finished code. But some things should not be done early. A prime example is optimization.

Optimization reduces the clarity and extensibility of the system in order to improve performance. That is a trade-off you need to make after all, a system does have to be fast enough to meet users' requirements. But optimizing too early makes development tougher, so this is one thing that does need to be left to the end.

During transition, there is no development to add functionality, unless it is small and absolutely essential. There is development to fix bugs. A good example of a transition phase is that time between the beta release and the final release of a product.

Patterns

The UML tells you how to express an object-oriented design. Patterns look, instead, at the results of the process: example models.

Many people have commented that projects have problems because the people involved were not aware of designs that are well known to those with more experience. Patterns describe common ways of doing things. They are collected by people who spot repeating themes in designs. These people take each theme and describe it so that other people can read the pattern and see how to apply it.

Let's look at an example. Say you have some objects running in a process on your desktop, and they need to communicate with other objects running in another process. Perhaps this process is also on your desktop; perhaps it resides elsewhere. You don't want the objects in your system to have to worry about finding other objects on the network or executing remote procedure calls.

What you can do is create a proxy object within your local process for the remote object. The proxy has the same interface as the remote object. Your local objects talk to the proxy using the usual in-process message sends. The proxy then is responsible for passing any messages on to the real object, wherever it might reside.

Figure 2-2 is a class diagram (see Chapter 4) that illustrates the structure of the Proxy pattern.

Figure 2-2. Structure of Proxy Design Pattern

Proxies are a common technique used in networks and elsewhere. People have a lot of experience using proxies in terms of knowing how they can be used, what advantages they can bring, their limitations, and how to implement them. Methods books like this one don't discuss this knowledge; all they discuss is how you can diagram a proxy. Although useful, it is not as useful as discussing the experience involving proxies.

In the early 1990s, some people began to capture this experience. They formed a community interested in writing patterns. These people sponsor conferences and have produced several books.

The most famous patterns book to emerge from this group is the Gang of Four book (Gamma, Helm, Johnson, and Vlissides 1995), which discusses 23 design patterns in detail.

If you want to know about proxies, this is the source. The Gang of Four book spends 10 pages on the subject, giving details about how the objects work together, the benefits and limitations of the pattern, common variations and usages, and implementation tips for Smalltalk and C++.

Proxy is a design pattern because it describes a design technique. Patterns can also exist in other areas. Say you are designing a system for managing risk in financial markets. You need to understand how the value of a portfolio of stocks changes over time. You could do this by keeping a price for each stock and timestamping the price. However, you also want to be able to consider the risk in hypothetical situations (for instance, "What will happen if the price of oil collapses?").

To do this, you can create a Scenario that contains a whole set of prices for stocks. Then you can have separate Scenarios for the prices last week, your best guess for next week, your guess for next week if oil prices collapse, and so forth. This Scenario pattern (see Figure 2-3) is an analysis pattern because it describes a piece of domain modeling.

Figure 2-3. Scenario Analysis Pattern

Analysis patterns are valuable because they give you a better start when you work with a new domain. I started collecting analysis patterns because I was frustrated by new domains. I knew I wasn't the first person to model them, yet each time I had to start with a blank sheet of paper.

The interesting thing about analysis patterns is that they crop up in unusual places. When I started working on a project to do corporate financial analysis, I was enormously helped by a set of patterns I had previously discovered in health care.

See Fowler (1997) to learn more about Scenario and other analysis patterns.

A pattern is much more than a model. A pattern must also include the reason why it is the way it is. It is often said that a pattern is a solution to a problem. The pattern must make the problem clear, explain why it solves the problem, and also explain in what circumstances it works and does not work.

Patterns are important because they are the next stage beyond understanding the basics of a language or a modeling technique. Patterns give you a series of solutions and also show you what makes a good model and how you go about constructing a model. They teach by example.

When I started out, I wondered why I had to invent things from scratch. Why didn't I have handbooks to show me how to do common things? The patterns community is trying to build these handbooks.

When to Use Patterns

Whenever you try to develop something in analysis, design, coding, or project management, you should search for any available patterns that might help you.

Where to Find Out More

The books I mentioned earlier are a good starting point on patterns. To go further, take a look at the patterns home page: <http://www.hillside.net/patterns>. This gives you good up-to-date information on the state of the patterns world.