If Only Coding Were Simple

The code in Listing 1.1 is for a Java program that outputs the text "hello world" to the command line. The listing is essentially a complete program, and it's simple. A bigger program, which is not rocket science to create, would involve code like that in Listing 1.1 but repeated with more classes that have more methods .

Listing 1.1

 public class Initial { public static void Main(String args[]) { System.out.println("hello world"); } } 

 

Consider Listing 1.2, which references a series of simple calculations.

Listing 1.2

 3 x 3 = 9 3 + 3 = 6 3  3 = 0 3 / 3 = 1 

 

In Listing 1.2, the calculations are singular, simple calculations. You can combine such calculations as shown in Listing 1.3.

Listing 1.3

 3 x 3 + 3 / 3 = 10 

 

Listing 1.3 is more complex than Listing 1.2. However, Listing 1.3 is not more difficult to figure out because when presented with the equation of Listing 1.3, you automatically simplify the equation into the discrete parts . For Listing 1.3, this means performing the multiplication, then the division, and finally the addition.

When you develop software, however, the same simplification into discrete operations is not done. Although software designers and architects do perform an analysis and attempt to decompose the problem much like is done in Listing 1.3, the notion of performing an action is missing in the object design. A typical software designer and architect will consider Listing 1.3 as four instances of the number 3 that have the operations multiple, add, and divide. Instead, the overall thought should be that the three operations multiple, add, and divide are base operations from which objects could be designed. The approach is slightly different and is task-based , in that the tasks are defined and then solved . The purpose of this book is to define and provide solutions for common tasks.

Managing Complexity

The problem of software architectures is that software is exponentially complex, and building that software is complex. You can manage complexity in two ways. You can solve a specific problem either by abstracting the complexity into smaller pieces of functionality that are layered and assembled, or by defining repeating pieces of functionality that you have assembled .

Think of it as follows . Imagine playing with Legos and building a house. There are two ways to build a house. The first way is to use entirely base blocks and build everything with those blocks. Some things will not be perfect in shape, but at least the same block is used and it is up to the builder to make it all appear right. The second way is to build the house, but have many specialized pieces that represent parts of the house. The disadvantage of this approach is that many parts are not reusable because they serve only one purpose.

In the software world, the objective is typically to create software in layers that are assembled to make an application. It is the hope of every software engineer to build his layers such that they are reusable in different contexts. Software engineers also attempt to make their layers future-proof and easier to extend and maintain. The problem is that software engineers build the house using specialized building blocks and hope that those building blocks are needed again. Again, the better approach is to decompose the problem into a number of tasks.

The Limitations of Patterns

Patterns in the software world represent solutions to common problems. For example, when you're creating an object, various creational-type patterns illustrate what the best strategy is when an object is created. Patterns teach the user to think in concepts and abstract ideas. Thinking in patterns and concepts is useful and helps us develop better software.

Patterns present a problem in terms of limitations, as they are too focused and require too much memorization. So, although this book will demonstrate some patterns in the context of programs, this book will not be about patterns.

The book Design Patterns, Elements of Reusable Object Oriented Software (Addison-Wesley, 1994) by the original "Gang of Four" pattern authors defines the concept of a pattern and implementation using the following steps:

1. Read and inspect the pattern.

2. Reread and understand the pattern's structure, participants , and collaborations.

3. Look at the sample code and understand the example.

4. Choose names for the participants that are useful in the context of the problem.

5. Apply the pattern and appropriately rename the individual classes, interfaces, and so on for the context of the problem.

6. Rename the operations of the pattern that are useful for the context of the problem.

7. Implement the operations of the pattern that are useful for the context of the problem.

After you carry out these steps for a single pattern, you repeat the process for all of the patterns necessary in the entire application. Doing the pattern application for multiple contexts becomes very tedious and complicates the development process.

What this book is trying to say in the end is that patterns in themselves are not bad, but rather are very useful. However, patterns tend to be more useful when they are used in general, not in specific. For example, instead of remembering ten different factory patterns used to create an object, think of only the concept of the factory pattern.