Contents

Preface 8

Introduction 11

The Y2K syndrome. 11

Context and composition. 12

A word about checked exceptions 13

The pattern concept 15

What is a pattern?. 15

Pattern taxonomy. 17

Design principles. 18

Classifying patterns. 19

The development challenge. 21

Unit testing. 21

Location of test code. 22

Simplifying Idioms 22

Messenger. 22

Collecting Parameter. 24

Object quantity 25

Singleton. 25

Exercises. 27

Object pool 27

Exercises. 30

Object decoupling 30

Proxy: fronting for another object 31

The PoolManager using Proxy. 33

Dynamic Proxies. 36

State: changing object behavior 38

Iterators: decoupling algorithms from containers 44

Type-safe iterators. 45

Exercises. 46

Factoring commonality 47

Strategy: choosing the algorithm at run-time 48

Policy: generalized strategy. 50

Template method. 50

Exercises. 52

Encapsulating creation 52

Simple Factory method. 53

Polymorphic factories. 55

Abstract factories. 58

Exercises. 61

Specialized creation 61

Prototype. 61

Builder. 62

Exercises. 66

Too many 66

Flyweight: too many objects. 66

Decorator: too many classes. 69

Basic decorator structure. 70

A coffee example. 70

Class for each combination. 70

The decorator approach. 73

Compromise. 78

Other considerations. 82

Exercises. 83

Connecting different types 84

Adapter. 84

Bridge. 87

Exercises. 93

Flexible structure 93

Composite. 93

System decoupling 95

Observer. 95

Observing flowers. 97

A visual example of observers. 101

Mediator. 103

Exercises. 104

Reducing interface complexity 104

Façade. 105

Package as a variation of Façade 106

Algorithmic partitioning 106

Command: choosing the operation at run-time 106

Exercises. 109

Chain of responsibility. 109

Exercises. 112

Externalizing object state 113

Memento. 113

Complex interactions 114

Multiple dispatching. 114

Visitor, a type of multiple dispatching 117

Exercises. 119

Multiple languages 120

Interpreter motivation. 121

Python overview.. 122

Built-in containers. 123

Functions. 124

Strings. 125

Classes. 127

Creating a language. 130

Controlling the interpreter. 134

Putting data in. 134

Getting data out. 140

Multiple interpreters. 143

Controlling Java from Jython 144

Inner Classes. 148

Using Java libraries. 148

Inheriting from Java library classes 150

Creating Java classes with Jython 151

Building the Java classes from the Python code 156

The Java-Python Extension (JPE) 157

Summary. 157

Exercises. 158

Complex system states 159

StateMachine. 159

Exercises. 169

Table-Driven State Machine. 169

The State class. 171

Conditions for transition. 172

Transition actions. 172

The table. 172

The basic machine. 173

Simple vending machine. 174

Testing the machine. 179

Tools. 180

Table-driven code: configuration flexibility 180

Table-driven code using anonymous inner classes 180

Exercises. 180

Pattern refactoring 181

Simulating the trash recycler. 182

Improving the design. 186

“Make more objects”. 186

A pattern for prototyping creation 189

Trash subclasses. 193

Parsing Trash from an external file 195

Recycling with prototyping. 198

Abstracting usage. 199

Multiple dispatching. 203

Implementing the double dispatch 204

The Visitor pattern. 211

A Reflective Decorator. 214

More coupling?. 219

RTTI considered harmful?. 220

Summary. 223

Exercises. 224

Projects 225

Rats & Mazes. 225

Other maze resources. 230

XML Decorator. 230

A: Tools 230

Ant extensions. 231

Array utilities. 232

Preface

The material in this book has been developed in conjunction with a seminar that I have given for several years, mostly with Bill Venners. Bill and I have given many iterations of this seminar and we’ve changed it many times over the years as we both have learned more about patterns and about giving the seminar.

In the process we’ve both produced more than enough information for us each to have our own seminars, an urge that we’ve both strongly resisted because we have so much fun giving the seminar together. We’ve given the seminar in numerous places in the US, as well as in Prague (where we try to have a mini-conference every Spring together with a number of other seminars). We’ve also given it as an on-site seminar.

A great deal of appreciation goes to the people who have participated in these seminars over the years, as they have helped me work through these ideas and to refine them. I hope to be able to continue to form and develop these kinds of ideas through this book and seminar for many years to come.

This book will not stop here, either. After much pondering, I’ve realized that I want Thinking in Python to be, initially, a translation of this book rather than an introduction to Python (there are already plenty of fine introductions to that superb language). I find this prospect to be much more exciting than the idea of struggling through another language tutorial (my apologies to those who were hoping for that).

#[BT_2]#

Introduction

This is a book about design that I have been working on for years, basically ever since I first started trying to read Design Patterns (Gamma, Helm, Johnson & Vlissides, Addison-Wesley, 1995), commonly referred to as the Gang of Four[1] or just GoF).

There is a chapter on design patterns in the first edition of Thinking in C++, which has evolved in Volume 2 of the second edition of Thinking in C++, and you’ll also find a chapter on patterns in the first edition of Thinking in Java (I took it out of the second edition because that book was getting too big, and also because I had decided to write this book).

This is not an introductory book. I am assuming that you have worked your way through Thinking in Java or an equivalent text before coming to this book.

In addition, I assume you have more than just a grasp of the syntax of Java. You should have a good understanding of objects and what they’re about, including polymorphism. Again, these are topics covered in Thinking in Java.

On the other hand, by going through this book you’re going to learn a lot about object-oriented programming by seeing objects used in many different situations. If your knowledge of objects is rudimentary, it will get much stronger in the process of understanding the designs in this book.

The Y2K syndrome

In a book that has “problem-solving techniques” in its subtitle, it’s worth mentioning one of the biggest pitfalls in programming: premature optimization. Every time I bring this concept forward, virtually everyone agrees to it. Also, everyone seems to reserve in their own mind a special case “except for this thing that I happen to know is a particular problem.”

The reason I call this the Y2K syndrome has to do with that special knowledge. Computers are a mystery to most people, so when someone announced that those silly computer programmers had forgotten to put in enough digits to hold dates past the year 1999, then suddenly everyone became a computer expert – “these things aren’t so difficult after all, if I can see such an obvious problem.” For example, my background was originally in computer engineering, and I started out by programming embedded systems. As a result, I know that many embedded systems have no idea what the date or time is, and even if they do that data often isn’t used in any important calculations. And yet I was told in no uncertain terms that all the embedded systems were going to crash on January 1, 2000. As far as I can tell the only memory that was lost on that particular date was that of the people who were predicting doom – it’s as if they had never said any of that stuff.

The point is that it’s very easy to fall into a habit of thinking that the particular algorithm or piece of code that you happen to partly or thoroughly understand is naturally going to be the bottleneck in your system, simply because you can imagine what’s going on in that piece of code and so you think that it must somehow be much less efficient than all the other pieces of code that you don’t know about. But unless you’ve run actual tests, typically with a profiler, you can’t really know what’s going on. And even if you are right, that a piece of code is very inefficient, remember that most programs spend something like 90% of their time in less than 10% of the code in the program, so unless the piece of code you’re thinking about happens to fall into that 10% it isn’t going to be important.

“We should forget about small efficiencies, say about 97% of the time: Premature optimization is the root of all evil.”—Donald Knuth

Context and composition

One of the terms you will see used over and over in design patterns literature is context. In fact, one common definition of a design pattern is “a solution to a problem in a context.” The GoF patterns often have a “context object” that the client programmer interacts with. At one point it occurred to me that such objects seemed to dominate the landscape of many patterns, and so I began asking what they were about.

The context object often acts as a little façade to hide the complexity of the rest of the pattern, and in addition it will often be the controller that manages the operation of the pattern. Initially, it seemed to me that these were not really essential to the implementation, use and understanding of the pattern. However, I remembered one of the more dramatic statements made in the GoF: “prefer composition to inheritance.” The context object allows you to use the pattern in a composition, and that may be it’s primary value.

A word about checked exceptions

1) The great value of exceptions is the unification of error reporting: a standard mechanism by which to report errors, rather than the popourri of ignorable approaches that we had in C (and thus, C++, which only adds exceptions to the mix, and doesn't make it the exclusive approach). The big advantage Java has over C++ is that exceptions are the only way to report errors.

2) "Ignorable" in the previous paragraph is the other issue. The theory is that if the compiler forces the programmer to either handle the exception or pass it on in an exception specification, then the programmer's attention will always be brought back to the possibility of errors and they will thus properly take care of them. I think the problem is that this is an untested assumption we're making as language designers that falls into the field of psychology. My theory is that when someone is trying to do something and you are constantly prodding them with annoyances, they will use the quickest device available to make those annoyances go away so they can get their thing done, perhaps assuming they'll go back and take out the device later. I discovered I had done this in the first edition of Thinking in Java:

And then more or less forgot it until the rewrite. How many people thought this was a good example and followed it? Martin Fowler began seeing the same kind of code, and realized people were stubbing out exceptions and then they were disappearing. The overhead of checked exceptions was having the opposite effect of what was intended, something that can happen when you experiment (and I now believe that checked exceptions were an experiment based on what someone thought was a good idea, and which I believed was a good idea until recently).

When I started using Python, all the exceptions appeared, none were accidentally "disappeared." If you *want* to catch an exception, you can, but you aren't forced to write reams of code all the time just to be passing the exceptions around. They go up to where you want to catch them, or they go all the way out if you forget (and thus they remind you) but they don't vanish, which is the worst of all possible cases. I now believe that checked exceptions encourage people to make them vanish. Plus they make much less readable code.

In the end, I think we must realize the experimental nature of exceptions and look at them carefully before assuming that everything about exceptions in Java are good. I believe that having a single mechanism for handling errors is excellent, and I believe that using a separate channel (the exception handling mechanism) for moving the exceptions around is good. But I do remember one of the early arguments for exception handling in C++ was that it would allow the programmer to separate the sections of code where you just wanted to get work done from the sections where you handled errors, and it seems to me that checked exceptions do not do this; instead, they tend to intrude (a lot) into your "normal working code" and thus are a step backwards. My experience with Python exceptions supports this, and unless I get turned around on this issue I intend to put a lot more RuntimeExceptions into my Java code.

#[BT_4]#

The pattern concept

“Design patterns help you learn from others' successes instead of your own failures[2].”

#[BT_6]#Probably the most important step forward in object-oriented design is the “design patterns” movement, chronicled in Design Patterns (ibid)[3]. That book shows 23 different solutions to particular classes of problems. In this book, the basic concepts of design patterns will be introduced along with examples. This should whet your appetite to read Design Patterns by Gamma, et. al., a source of what has now become an essential, almost mandatory, vocabulary for OOP programmers.

#[BT_7]#The latter part of this book contains an example of the design evolution process, starting with an initial solution and moving through the logic and process of evolving the solution to more appropriate designs. The program shown (a trash sorting simulation) has evolved over time, and you can look at that evolution as a prototype for the way your own design can start as an adequate solution to a particular problem and evolve into a flexible approach to a class of problems.

What is a pattern?

#[BT_8]#Initially, you can think of a pattern as an especially clever and insightful way of solving a particular class of problems. That is, it looks like a lot of people have worked out all the angles of a problem and have come up with the most general, flexible solution for it. The problem could be one you have seen and solved before, but your solution probably didn’t have the kind of completeness you’ll see embodied in a pattern.

#[BT_9]#Although they’re called “design patterns,” they really aren’t tied to the realm of design. A pattern seems to stand apart from the traditional way of thinking about analysis, design, and implementation. Instead, a pattern embodies a complete idea within a program, and thus it can sometimes appear at the analysis phase or high-level design phase. This is interesting because a pattern has a direct implementation in code and so you might not expect it to show up before low-level design or implementation (and in fact you might not realize that you need a particular pattern until you get to those phases).

#[BT_10]#The basic concept of a pattern can also be seen as the basic concept of program design: adding a layer of abstraction. Whenever you abstract something you’re isolating particular details, and one of the most compelling motivations behind this is to separate things that change from things that stay the same. Another way to put this is that once you find some part of your program that’s likely to change for one reason or another, you’ll want to keep those changes from propagating other changes throughout your code. Not only does this make the code much cheaper to maintain, but it also turns out that it is usually simpler to understand (which results in lowered costs).

#[BT_11]#Often, the most difficult part of developing an elegant and cheap-to-maintain design is in discovering what I call “the vector of change.” (Here, “vector” refers to the maximum gradient and not a container class.) This means finding the most important thing that changes in your system, or put another way, discovering where your greatest cost is. Once you discover the vector of change, you have the focal point around which to structure your design.

#[BT_12]#So the goal of design patterns is to isolate changes in your code. If you look at it this way, you’ve been seeing some design patterns already in this book. For example, inheritance can be thought of as a design pattern (albeit one implemented by the compiler). It allows you to express differences in behavior (that’s the thing that changes) in objects that all have the same interface (that’s what stays the same). Composition can also be considered a pattern, since it allows you to change—dynamically or statically—the objects that implement your class, and thus the way that class works.

#[BT_13]#You’ve also already seen another pattern that appears in Design Patterns: the iterator (Java 1.0 and 1.1 capriciously calls it the Enumeration; Java 2 containers use “iterator”). This hides the particular implementation of the container as you’re stepping through and selecting the elements one by one. The iterator allows you to write generic code that performs an operation on all of the elements in a sequence without regard to the way that sequence is built. Thus your generic code can be used with any container that can produce an iterator.

Pattern taxonomy

#[BT_14]#One of the events that’s occurred with the rise of design patterns is what could be thought of as the “pollution” of the term – people have begun to use the term to mean just about anything synonymous with “good.” After some pondering, I’ve come up with a sort of hierarchy describing a succession of different types of categories:

1.      #[BT_15]#Idiom: how we write code in a particular language to do this particular type of thing. This could be something as common as the way that you code the process of stepping through an array in C (and not running off the end).

2.     #[BT_16]#Specific Design: the solution that we came up with to solve this particular problem. This might be a clever design, but it makes no attempt to be general.

3.     #[BT_17]#Standard Design: a way to solve this kind of problem. A design that has become more general, typically through reuse.

4.     #[BT_18]#Design Pattern: how to solve an entire class of similar problem. This usually only appears after applying a standard design a number of times, and then seeing a common pattern throughout these applications.

#[BT_19]#I feel this helps put things in perspective, and to show where something might fit. However, it doesn’t say that one is better than another. It doesn’t make sense to try to take every problem solution and generalize it to a design pattern – it’s not a good use of your time, and you can’t force the discovery of patterns that way; they tend to be subtle and appear over time.

#[BT_20]#One could also argue for the inclusion of Analysis Pattern and Architectural Pattern in this taxonomy.

Design principles

(Update from slides to here)

When I put out a call for ideas in my newsletter[4], a number of suggestions came back which turned out to be very useful, but different than the above classification, and I realized that a list of design principles is at least as important as design structures, but for a different reason: these allow you to ask questions about your proposed design, to apply tests for quality.

·         Principle of least astonishment (don’t be astonishing).

·         Make common things easy, and rare things possible

·         Consistency. One thing has become very clear to me, especially because of Python: the more random rules you pile onto the programmer, rules that have nothing to do with solving the problem at hand, the slower the programmer can produce. And this does not appear to be a linear factor, but an exponential one.

·         Law of Demeter: a.k.a. “Don’t talk to strangers.” An object should only reference itself, its attributes, and the arguments of its methods.

·         Subtraction: a design is finished when you cannot take anything else away.

·         Simplicity before generality[5]. (A variation of Occam’s Razor, which says “the simplest solution is the best”). A common problem we find in frameworks is that they are designed to be general purpose without reference to actual systems. This leads to a dizzying array of options that are often unused, misused or just not useful. However, most developers work on specific systems, and the quest for generality does not always serve them well. The best route to generality is through understanding well-defined specific examples. So, this principle acts as the tie breaker between otherwise equally viable design alternatives. Of course, it is entirely possible that the simpler solution is the more general one.

·         Reflexivity (my suggested term). One abstraction per class, one class per abstraction. Might also be called Isomorphism.

·         Independence or Orthogonality. Express independent ideas independently. This complements Separation, Encapsulation and Variation, and is part of the Low-Coupling-High-Cohesion message.

·         Once and once only: Avoid duplication of logic and structure where the duplication is not accidental, ie where both pieces of code express the same intent for the same reason.

In the process of brainstorming this idea, I hope to come up with a small handful of fundamental ideas that can be held in your head while you analyze a problem. However, other ideas that come from this list may end up being useful as a checklist while walking through and analyzing your design.

Classifying patterns

#[BT_27]#The Design Patterns book discusses 23 different patterns, classified under three purposes (all of which revolve around the particular aspect that can vary). The three purposes are:

1.              Creational: how an object can be created. This often involves isolating the details of object creation so your code isn’t dependent on what types of objects there are and thus doesn’t have to be changed when you add a new type of object. The aforementioned Singleton is classified as a creational pattern, and later in this book you’ll see examples of Factory Method and Prototype.

2.              Structural: designing objects to satisfy particular project constraints. These work with the way objects are connected with other objects to ensure that changes in the system don’t require changes to those connections.

3.              Behavioral: objects that handle particular types of actions within a program. These encapsulate processes that you want to perform, such as interpreting a language, fulfilling a request, moving through a sequence (as in an iterator), or implementing an algorithm. This book contains examples of the Observer and the Visitor patterns.

#[BT_28]#The Design Patterns book has a section on each of its 23 patterns along with one or more examples for each, typically in C++ (rather restricted C++, at that) but sometimes in Smalltalk. (You’ll find that this doesn’t matter too much since you can easily translate the concepts from either language into Java.) This book will revisit many of the patterns shown in Design Patterns but with a Java orientation, since the language changes the expression and understanding of the patterns. However, the GoF examples will not be repeated here, since I believe that it’s possible to produce more illuminating examples given some effort. The goal is to provide you with a decent feel for what patterns are about and why they are so important.

#[BT_29]#After years of looking at these things, it began to occur to me that the patterns themselves use basic principles of organization, other than (and more fundamental than) those described in Design Patterns. These principles are based on the structure of the implementations, which is where I have seen great similarities between patterns (more than those expressed in Design Patterns). Although we generally try to avoid implementation in favor of interface, for awhile I thought that it was easier to understand the patterns in terms of these structural principles, and tried reorganizing the book around the patterns based on their structure instead of the categories presented in Design Patterns.

However, a later insight made me realize that it’s more useful to organize the patterns in terms of the problems they solve. I believe this is a subtle but important distinction from the way Metsker organizes the patterns by intent in Design Patterns Java Workshop (Addison-Wesley 2002), because I hope that you will then be able to recognize your problem and search for a solution, if the patterns are organized this way.

In the process of doing all this “book refactoring” I realized that if I changed it once, I would probably change it again (there’s definitely a design maxim in there), so I removed all references to chapter numbers in order to facilitate this change (the little-known “numberless chapter” pattern J).HowHH

The development challenge

#[BT_30]#Issues of development, the UML process, Extreme Programming.

#[BT_31]#Is evaluation valuable? The Capability Immaturity Model:

#[BT_32]#Wiki Page: http://c2.com/cgi-bin/wiki?CapabilityImMaturityModel
Article: http://www.embedded.com/98/9807br.htm

#[BT_33]#Pair programming research:

#[BT_34]#http://collaboration.csc.ncsu.edu/laurie/

Unit testing

In an earlier version of this book I decided that unit testing was essential (for all of my books) and that JUnit was too verbose and clunky to consider. At that time I wrote my own unit testing framework using Java reflection to simplify the syntax necessary to achieve unit testing. For the third edition of Thinking in Java, we developed another unit testing framework for that book which would test the output of examples.

In the meantime, JUnit has changed to add a syntax remarkably similar to the one that I used in an earlier version of this book. I don’t know how much influence I may have had on that change, but I’m simply happy that it has happened, because I no longer feel the need to support my own system (which you can still find <some URL here>) and can simply recommend the defacto standard.

I have introduced and described the style of JUnit coding that I consider a “best practice” (primarily because of simplicity), in Thinking in Java, 3^rd edition, chapter 15. That section provides an adequate introduction to any of the unit testing you will see associated with this book (however, the unit testing code will not normally be included in the text of this book). When you download the code for this book, you will find (4/9/2003: Eventually, not yet) unit tests along with the code examples whenever possible.

Location of test code

(From Bill):

Public: in test subdirectory; different package (don’t include in jar).

Package access: same package, subdirectory path underneath library code (don’t include in jar)

Private access: (white box testing). Nested class, strip out, or Junit addons.

Simplifying Idioms

Before getting into more complex techniques, it’s helpful to look at some basic ways to keep code simple and straightforward.

Messenger

The most trivial of these is the messenger, which simply packages information into an object to be passed around, instead of passing all the pieces around separately. Note that without the messenger, the code for translate() would be much more confusing to read:

Since the goal of a messenger is only to carry data, that data is made public for easy access. However, you may also have reasons to make the fields private.

Collecting Parameter

Messenger’s big brother is the collecting parameter, whose job is to capture information from the method to which it is passed. Generally, this is used when the collecting parameter is passed to multiple methods, so it’s like a bee collecting pollen.

A container makes an especially useful collecting parameter, since it is already set up to dynamically add objects:

The collecting parameter must have some way to set or insert values. Note that by this definition, a messenger could be used as a collecting parameter. The key is that a collecting parameter is passed about and modified by the methods it is passed to.

Object quantity

The two patterns described here are solely used to control the quantity of objects.

Singleton could actually be thought of as a special case of Object Pool, but the applications of the Object Pool tend to be uniqe enough from Singleton that it’s worth treating the two separately.

Singleton

#[BT_21]#Possibly the simplest design pattern is the singleton, which is a way to provide one and only one object of a particular type. An important aspect of Singleton is that you provide a global access point, so singletons are often a solution for what you would have used a global variable for in C. In addition, a singleton often has the characteristics of a registry or lookup service – it’s a place you go to find references to other objects.

Singletons can be found in the Java libraries, but here’s a more direct example:

#[BT_22]#

#[BT_23]#The key to creating a singleton is to prevent the client programmer from having any way to create an object except the ways you provide. You must make all constructors private, and you must create at least one constructor to prevent the compiler from synthesizing a default constructor for you (which it will create using package access).

#[BT_24]#At this point, you decide how you’re going to create your object. Here, it’s created statically, but you can also wait until the client programmer asks for one and create it on demand. In any case, the object should be stored privately. You provide access through public methods. Here, getReference( ) produces the reference to the Singleton object. The rest of the interface (getValue( ) and setValue( )) is the regular class interface.

#[BT_25]#Java also allows the creation of objects through cloning. In this example, making the class final prevents cloning. Since Singleton is inherited directly from Object, the clone( ) method remains protected so it cannot be used (doing so produces a compile-time error). However, if you’re inheriting from a class hierarchy that has already overridden clone( ) as public and implemented Cloneable, the way to prevent cloning is to override clone( ) and throw a CloneNotSupportedException as described in Appendix A of Thinking in Java, 2^nd edition. (You could also override clone( ) and simply return this, but that would be deceiving since the client programmer would think they were cloning the object, but would instead still be dealing with the original.) Actually, this isn’t precisely true, because even in the above situation someone could still use reflection to invoke clone( ) [[is this true? clone( ) is still protected so I’m not so sure. If it is true, you’d have to throw CloneNotSupportedException as the only way to guarantee un-cloneability ]]

Exercises

             1.             SingletonPattern.java always creates an object, even if it’s never used. Modify this program to use lazy initialization, so the singleton object is only created the first time that it is needed.

             2.             Create a registry/lookup service that accepts a Java interface and produces a reference to an object that implements that interface.

Object pool

#[BT_26]#Note that you aren’t restricted to creating only one object. This is also a technique to create a limited pool of objects. In that situation, however, you can be confronted with the problem of sharing objects in the pool. If this is an issue, you can create a solution involving a check-out and check-in of the shared objects.AsAAAAA

As an example, consider a database. Commercial databases often restrict the number of connections that you can use at any one time. Here is an implementation that uses an object pool to manage the connections. First, the basic concept of managing a pool of objects is implemented as a separate class:

Exercises

             1.             Add unit tests to ConnectionPoolDemo.java to demonstrate the problem that the client may release the connection but still continue to use it.

#[BT_35]#

#[BT_36]#

Object decoupling

#[BT_92]#Both Proxy and State provide a surrogate class that you use in your code; the real class that does the work is hidden behind this surrogate class. When you call a method in the surrogate, it simply turns around and calls the method in the implementing class. These two patterns are so similar that the Proxy is simply a special case of State. One is tempted to just lump the two together into a pattern called Surrogate, but the term “proxy” has a long-standing and specialized meaning, which probably explains the reason for the two different patterns.

#[BT_93]#The basic idea is simple: from a base class, the surrogate is derived along with the class or classes that provide the actual implementation:

#[BT_94]#

#[BT_95]#When a surrogate object is created, it is given an implementation to which to send all of the method calls.

#[BT_96]#Structurally, the difference between Proxy and State is simple: a Proxy has only one implementation, while State has more than one. The application of the patterns is considered (in Design Patterns) to be distinct: Proxy is used to control access to its implementation, while State allows you to change the implementation dynamically. However, if you expand your notion of “controlling access to implementation” then the two fit neatly together.

Proxy: fronting for another object

#[BT_97]#If we implement Proxy by following the above diagram, it looks like this:

#[BT_98]#

#[BT_99]#Of course, it isn’t necessary that Implementation have the same interface as Proxy; as long as Proxy is somehow “speaking for” the class that it is referring method calls to then the basic idea is satisfied (note that this statement is at odds with the definition for Proxy in GoF). However, it is convenient to have a common interface so that Implementation is forced to fulfill all the methods that Proxy needs to call.

The PoolManager using Proxy

Dynamic Proxies

In JDK 1.3, the Dynamic Proxy was introduced. Although a little complex at first, this is an intruiging tool.

Here's an interesting little starting example, which works and proves that yes, indeed, the invocation handler is being called so the proxying etc. is actually working. So it's pretty cool, and it's in my head now, but I still have to figure out something reasonable to do with the invocation handler to come up with a useful example...

Exercise: Use the Java dynamic proxy to create an object that acts as a front end for a simple configuration file. For example, in good_stuff.txt you can have entries like this:

A client programmer of this NeatPropertyBundle could then write:

The contents of the configuration file can contain anything, with any variable names. The dynamic proxy will either map to the name or tell you it doesn’t exist somehow (probably by returning null). If you set a property and it doesn’t already exist, the dynamic proxy will create the new entry. The toString( ) method should display all the current entries.

Exercise: similar to the previous exercise, use the Java dynamic proxy to make a connection to the DOS Autoexec.bat file.

Exercise: Accept an SQL query which returns data, then read the DB metadata. Now, for each record, provide an object which has attributes corresponding to the column names and of appropriate data types.

Exercise: Create a simple server and client that uses XML-RPC. Each object the client returns should use the dynamic proxy concept to exercise the remote methods.

Andrea writes:

I'm not sure about the exercises you suggest, except for the last one. The thing is that I like to think at invocation handler as somthing providing features that are orthogonal to the ones provided by the object being "proxied".

In other words: the implementation of the invocation handler is completely independent from the interface(s) of the object that the dynamically-generated proxy represent. Which means that once you have implemented an invocation handler, you can use for any class that exposes interfaces, even for classes and interfaces that were not present when the handler was implemented.

That's why I say the the handler provides services that are orthogonal to the ones provided by the proxied object. Rickard has a few handlers in his SmartWorld example, and they one I like the best is a call-retry handler. It basically makes a call into the actual object, and if the call generates an exception if waits for a while, then makes the same call again for a total of three times. If all three calls fails, it returns an exception. And you can use such a handler on _any_ class.

The implementation is way too complex for what you are trying to demonstrate. I'm using this example just to explain what I mean by orthogonal services.

In your list of exercises, the only one that, in my opinion, makes sense to implement using dynamic proxies is the last one, the one using XML-RPC to communicate with an object. And that's because the mechanism you use to dispatch the message (XML-RPC) is orthogonal to the services provided by the object you want to reach.

State: changing object behavior

An object that appears to change its class.

Indications: conditional code in most or all methods.

#[BT_100]#The State pattern switches from one implementation to another during the lifetime of the surrogate, in order to produce different behavior from the same method call(s). It’s a way to improve the implementation of your code when you seem to be doing a lot of testing inside each of your methods before deciding what to do for that method. For example, the fairy tale of the frog-prince contains an object (the creature) that behaves differently depending on what state it’s in. You could implement this using a boolean that you test:

However, the greet() method, and any other methods that must test isFrog before they perform their operations, ends up with awkward code. By delegating the operations to a State object that can be changed, this code is simplified.

In addition, changes to the State are automatically propagated throughout, rather than requiring an edit across the class methods in order to effect changes.

Here’s the basic structure of State:[[ [[

#[BT_101]#

#[BT_102]#In main( ), you can see that the first implementation is used for a bit, then the second implementation is swapped in and that is used.

There are a number of details that are choices that you must make according to the needs of your own implementation, such as whether the fact that you are using State is exposed to the client, and how the changes to State are made. Sometimes (as in the Swing LayoutManager) the client may pass in the object directly, but in KissingPrincess2.java the fact that State is used is invisible to the client. In addition, the mechanism for changing state may be simple or complex – in State Machine, described later in this book, larger sets of states and different mechanisms for changing are explored.

The Swing LayoutManager example mentioned above is an interesting example because it show behavior of both Strategy and State.

#[BT_103]#The difference between Proxy and State is in the problems that are solved. The common uses for Proxy as described in Design Patterns are:

1.              Remote proxy. This proxies for an object in a different address space. A remote proxy is created for you automatically by the RMI compiler rmic as it creates stubs and skeletons.

2.              Virtual proxy. This provides “lazy initialization” to create expensive objects on demand.

3.              Protection proxy. Used when you don’t want the client programmer to have full access to the proxied object.

4.              Smart reference. To add additional actions when the proxied object is accessed. For example, or to keep track of the number of references that are held for a particular object, in order to implement the copy-on-write idiom and prevent object aliasing. A simpler example is keeping track of the number of calls to a particular method.

#[BT_104]#You could look at a Java reference as a kind of protection proxy, since it controls access to the actual object on the heap (and ensures, for example, that you don’t use a null reference).

#[BT_105]#[[ Rewrite this: In Design Patterns, Proxy and State are not seen as related to each other because the two are given (what I consider arbitrarily) different structures. State, in particular, uses a separate implementation hierarchy but this seems to me to be unnecessary unless you have decided that the implementation is not under your control (certainly a possibility, but if you own all the code there seems to be no reason not to benefit from the elegance and helpfulness of the single base class). In addition, Proxy need not use the same base class for its implementation, as long as the proxy object is controlling access to the object it “fronting” for. Regardless of the specifics, in both Proxy and State a surrogate is passing method calls through to an implementation object.]]]

State can be found everywhere because it’s such a fundamental idea. For example, in Builder, the “Director” uses a backend Builder object to produce different behaviors.Stat

Iterators: decoupling algorithms from containers

Alexander Stepanov thought for years about the problem of generic programming techniques before creating the STL (along with Dave Musser). He came to the conclusion that all algorithms are defined on algebraic structures – what we would call containers.

#[BT_193]#In the process, he realized that iterators are central to the use of algorithms, because they decouple the algorithms from the specific type of container that the algorithm might currently be working with. This means that you can describe the algorithm without worrying about the particular sequence it is operating on. More generally, any code that you write using iterators is decoupled from the data structure that the code is manipulating, and thus your code is more general and reusable.

#[BT_194]#The use of iterators also extends your code into the realm of functional programming, whose objective is to describe what a program is doing at every step rather than how it is doing it. That is, you say “sort” rather than describing the sort. The objective of the C++ STL was to provide this generic programming approach for C++ (how successful this approach will actually be remains to be seen).

#[BT_195]#If you’ve used containers in Java (and it’s hard to write code without using them), you’ve used iterators – in the form of the Enumeration in Java 1.0/1.1 and the Iterator in Java 2. So you should already be familiar with their general use. If not, see Chapter 9, Holding Your Objects, under Iterators in Thinking in Java, 2^nd edition (freely downloadable from www.BruceEckel.com).

#[BT_196]#Because the Java 2 containers rely heavily on iterators they become excellent candidates for generic/functional programming techniques. This chapter will explore these techniques by converting the STL algorithms to Java, for use with the Java 2 container library.

Type-safe iterators

#[BT_197]#In Thinking in Java, 2^nd edition, I show the creation of a type-safe container that will only accept a particular type of object. A reader, Linda Pazzaglia, asked for the other obvious type-safe component, an iterator that would work with the basic java.util containers, but impose the constraint that the type of objects that it iterates over be of a particular type.

#[BT_198]#If Java ever includes a template mechanism, this kind of iterator will have the added advantage of being able to return a specific type of object, but without templates you are forced to return generic Objects, or to require a bit of hand-coding for every type that you want to iterate through. I will take the former approach.

#[BT_199]#A second design decision involves the time that the type of object is determined. One approach is to take the type of the first object that the iterator encounters, but this is problematic because the containers may rearrange the objects according to an internal ordering mechanism (such as a hash table) and thus you may get different results from one iteration to the next. The safe approach is to require the user to establish the type during construction of the iterator.

#[BT_200]#Lastly, how do we build the iterator? We cannot rewrite the existing Java library classes that already produce Enumerations and Iterators. However, we can use the Decorator design pattern, and create a class that simply wraps the Enumeration or Iterator that is produced, generating a new object that has the iteration behavior that we want (which is, in this case, to throw a RuntimeException if an incorrect type is encountered) but with the same interface as the original Enumeration or Iterator, so that it can be used in the same places (you may argue that this is actually a Proxy pattern, but it’s more likely Decorator because of its intent). Here is the code:

Exercises

             1.             Create an example of the “virtual proxy.”

             2.             Create an example of the “Smart reference” proxy where you keep count of the number of method calls to a particular object.

             3.             Create a program similar to certain DBMS systems that only allow a certain number of connections at any time. To implement this, use a singleton-like system that controls the number of “connection” objects that it creates. When a user is finished with a connection, the system must be informed so that it can check that connection back in to be reused. To guarantee this, provide a proxy object instead of a reference to the actual connection, and design the proxy so that it will cause the connection to be released back to the system.

             4.             Using the State pattern, make a class called UnpredictablePerson which changes the kind of response to its hello( ) method depending on what kind of Mood it’s in. Add an additional kind of Mood called Prozac.

             5.             Create a simple copy-on write implementation.

             6.             The java.util.Map has no way to automatically load a two-dimensional array of objects into a Map as key-value pairs. Create an adapter class that does this.

             7.             Create an Adapter Factory that dynamically finds and produces the adapter that you need to connect a given object to a desired interface.

             8.             Solve the above exercise using the dynamic proxy that’s part of the Java standard library.

             9.             Modify the Object Pool solution so that the objects are returned to the pool automatically after a certain amount of time.

        10.             Modify the above solution to use “leasing” so that the client can renew the lease on the object to prevent it from being automatically released by the timer.

        11.             Modify the Object Pool system to take threading issues into account.

Factoring commonality

Applying the “once and only once” principle produces the most basic pattern of putting code that changes into a method.

This can be expressed two ways:

Strategy: choosing the algorithm at run-time

#[BT_231]#Strategy also adds a “Context” which can be a surrogate class that controls the selection and use of the particular strategy object—just like State! Here’s what it looks like:

Note similarity with template method – TM claims distinction that it has more than one method to call, does things piecewise. However, it’s not unlikely that strategy object would have more than one method call; consider Shalloway’s order fulfullment system with country information in each strategy.

Strategy example from JDK: comparator objects.

Policy: generalized strategy

Although GoF says that Policy is just another name for strategy, their use of Strategy implicitly assumes a single method in the strategy object – that you’ve broken out your changing algorithm as a single piece of code.

Others[6] use Policy to mean an object that has multiple methods that may vary independently from class to class. This gives more flexibility than being restricted to a single method.

For example, a shipping policy for a product can be used to describe shipping issues for sending a package to various different countries. This may include the available methods of shipping, how to calculate postage or shipping cost, customs requirements and fees, and special handling costs. All these things may vary independently of each other, and more importantly you may need the information from each at different points in the shipping process.

It also seems generally useful to distinguish Strategies with single methods from Policies with multiple methods.

#[BT_232]#

#[BT_233]#

Template method

#[BT_86]#An application framework allows you to inherit from a class or set of classes and create a new application, reusing most of the code in the existing classes and overriding one or more methods in order to customize the application to your needs. A fundamental concept in the application framework is the Template Method which is typically hidden beneath the covers and drives the application by calling the various methods in the base class (some of which you have overridden in order to create the application).

#[BT_87]#For example, whenever you create an applet you’re using an application framework: you inherit from JApplet and then override init( ). The applet mechanism (which is a Template Method) does the rest by drawing the screen, handling the event loop, resizing, etc.

#[BT_88]#An important characteristic of the Template Method is that it is defined in the base class and cannot be changed. It’s sometimes a private method but it’s virtually always final. It calls other base-class methods (the ones you override) in order to do its job, but it is usually called only as part of an initialization process (and thus the client programmer isn’t necessarily able to call it directly).

#[BT_89]#

#[BT_90]#The base-class constructor is responsible for performing the necessary initialization and then starting the “engine” (the template method) that runs the application (in a GUI application, this “engine” would be the main event loop). The client programmer simply provides definitions for customize1( ) and customize2( ) and the “application” is ready to run.

Exercises

             1.             Create a framework that takes a list of file names on the command line. It opens each file except the last for reading, and the last for writing. The framework will process each input file using an undetermined policy and write the output to the last file. Inherit to customize this framework to create two separate applications:
1) Converts all the letters in each file to uppercase.
2) Searches the files for words given in the first file.

#[BT_91]#

Encapsulating creation

#[BT_203]#When you discover that you need to add new types to a system, the most sensible first step is to use polymorphism to create a common interface to those new types. This separates the rest of the code in your system from the knowledge of the specific types that you are adding. New types may be added without disturbing existing code … or so it seems. At first it would appear that the only place you need to change the code in such a design is the place where you inherit a new type, but this is not quite true. You must still create an object of your new type, and at the point of creation you must specify the exact constructor to use. Thus, if the code that creates objects is distributed throughout your application, you have the same problem when adding new types—you must still chase down all the points of your code where type matters. It happens to be the creation of the type that matters in this case rather than the use of the type (which is taken care of by polymorphism), but the effect is the same: adding a new type can cause problems.

#[BT_204]#The solution is to force the creation of objects to occur through a common factory rather than to allow the creational code to be spread throughout your system. If all the code in your program must go through this factory whenever it needs to create one of your objects, then all you must do when you add a new object is to modify the factory.

#[BT_205]#Since every object-oriented program creates objects, and since it’s very likely you will extend your program by adding new types, I suspect that factories may be the most universally useful kinds of design patterns.

Although only the Simple Factory Method is a true singleton, you’ll find that each specify factory class in the more general types of factories will only have a single instance.

Simple Factory method

#[BT_206]#As an example, let’s revisit the Shape system. #[BT_207]#

#[BT_208]#One approach is to make the factory a static method of the base class:

#[BT_209]#

#[BT_210]#The factory( ) takes an argument that allows it to determine what type of Shape to create; it happens to be a String in this case but it could be any set of data. The factory( ) is now the only other code in the system that needs to be changed when a new type of Shape is added (the initialization data for the objects will presumably come from somewhere outside the system, and not be a hard-coded array as in the above example).

#[BT_211]#To encourage creation to only happen in the factory( ), the constructors for the specific types of Shape are give package access, so factory( ) has access to the constructors but they are not available outside the package.

Polymorphic factories

#[BT_212]#The static factory( ) method in the previous example forces all the creation operations to be focused in one spot, so that’s the only place you need to change the code. This is certainly a reasonable solution, as it throws a box around the process of creating objects. However, the Design Patterns book emphasizes that the reason for the Factory Method pattern is so that different types of factories can be subclassed from the basic factory (the above design is mentioned as a special case). However, the book does not provide an example, but instead just repeats the example used for the Abstract Factory (you’ll see an example of this in the next section). Here is ShapeFactory1.java modified so the factory methods are in a separate class as virtual functions. Notice also that the specific Shape classes are dynamically loaded on demand:

#[BT_213]#

#[BT_214]#Now the factory method appears in its own class, ShapeFactory, as the create( ) method. This is a protected method which means it cannot be called directly, but it can be overridden. The subclasses of Shape must each create their own subclasses of ShapeFactory and override the create( ) method to create an object of their own type. The actual creation of shapes is performed by calling ShapeFactory.createShape( ), which is a static method that uses the Map in ShapeFactory to find the appropriate factory object based on an identifier that you pass it. The factory is immediately used to create the shape object, but you could imagine a more complex problem where the appropriate factory object is returned and then used by the caller to create an object in a more sophisticated way. However, it seems that much of the time you don’t need the intricacies of the polymorphic factory method, and a single static method in the base class (as shown in ShapeFactory1.java) will work fine.

#[BT_215]#Notice that the ShapeFactory must be initialized by loading its Map with factory objects, which takes place in the static initialization clause of each of the Shape implementations. So to add a new type to this design you must inherit the type, create a factory, and add the static initialization clause to load the Map. This extra complexity again suggests the use of a static factory method if you don’t need to create individual factory objects.

Abstract factories

#[BT_216]#The Abstract Factory pattern looks like the factory objects we’ve seen previously, with not one but several factory methods. Each of the factory methods creates a different kind of object. The idea is that at the point of creation of the factory object, you decide how all the objects created by that factory will be used. The example given in Design Patterns implements portability across various graphical user interfaces (GUIs): you create a factory object appropriate to the GUI that you’re working with, and from then on when you ask it for a menu, button, slider, etc. it will automatically create the appropriate version of that item for the GUI. Thus you’re able to isolate, in one place, the effect of changing from one GUI to another.

#[BT_217]#As another example suppose you are creating a general-purpose gaming environment and you want to be able to support different types of games. Here’s how it might look using an abstract factory:

#[BT_218]#

#[BT_219]#In this environment, Player objects interact with Obstacle objects, but there are different types of players and obstacles depending on what kind of game you’re playing. You determine the kind of game by choosing a particular GameElementFactory, and then the GameEnvironment controls the setup and play of the game. In this example, the setup and play is very simple, but those activities (the initial conditions and the state change) can determine much of the game’s outcome. Here, GameEnvironment is not designed to be inherited, although it could very possibly make sense to do that.

#[BT_220]#This also contains examples of Double Dispatching and the Factory Method, both of which will be explained later.

Exercises

             1.             Add a class Triangle to ShapeFactory1.java

             2.             Add a class Triangle to ShapeFactory2.java

             3.             Add a new type of GameEnvironment called GnomesAndFairies to Games.java

             4.             Modify ShapeFactory2.java so that it uses an Abstract Factory to create different sets of shapes (for example, one particular type of factory object creates “thick shapes,” another creates “thin shapes,” but each factory object can create all the shapes: circles, squares, triangles etc.).

#[BT_221]#

#[BT_222]#

Specialized creation

Prototype

Objects are created by cloning a prototypical instance. An example of this appears in the “Pattern Refactoring” chapter.

Builder

The goal of builder is to separate the construction from the “representation,” to allow multiple different representations. The construction process stays the same, but the resulting object has different possible representations. GoF points out that the main difference with Abstract Factory is that a Builder creates the object step-by-step, so the fact that the creation process is spread out in time seems to be important. In addition, it seems that the “director” gets a stream of pieces that it passes to the Builder, and each piece is used to perform one of the steps in the build process.

One example given in GoF is that of a text format converter. The incoming format is RTF, and once it is parsed the directives are passed to the text converter, which may be implemented in different ways depending on whether the resulting format is ASCII, TeX, or a “GUI Text Widget.” Although the resulting “object” (the entire converted text file) is created over time, if you consider the conversion of each RTF directive to be an object, this feels to me a little more like Bridge, because the specific types of converters extend the interface of the base class. Also, the general solution to the problem would allow multiple readers on the “front end” and multiple converters on the “back end,” which is a primary characteristic of Bridge.

To me, the fact that Builder has multiple steps in creating an object, and those steps are accessed externally to the Builder object, is the essence of what distinguishes it (structurally, anyway) from a regular factory. However, GoF emphasizes that you’re able to create different representations using the same process. They never define exactly what they mean by representation. (Does the “representation” involve an object that is too large? Would the need for Builder vanish if the representation was broken into smaller objects?)

The other example in GoF creates a maze object and adds rooms within the maze and doors within the rooms. Thus it is a multistep process, but alas, the different “representations” are the “Standard” and “Complex” mazes – not really different kinds of mazes, but instead different complexity. I think I would have tried to create one maze builder that could handle arbitrarily complex mazes. The final variation of the maze builder is something that doesn’t create mazes at all, but instead counts the rooms in an existing maze.

Neither the RTF converter nor the Mazebuilder example makes an overwhelmingly compelling case for Builder. Readers have suggested that the output of the Sax XML parser, and standard compiler parsers, might naturally be fed into a Builder.

Here’s an example that may be a little more compelling, or at least give more of an idea of what Builder is trying to do. Media may be constructed into different representations, in this case books, magazines and web sites. The example argues that the steps involved are the same, and so can be abstracted into the director class.

Note that in some ways this could be seen as a more complicated State pattern, since the behavior of the director depends on what type of builder you use. Instead of simply forwarding the requests through to the underlying State object, however, the director has a sequence of operations to perform, and it uses the State object as a Policy to fulfill its job. Thus, Builder could be described as using a Policy to create objects.

Exercises

             1.             Break a text file up into an input stream of words (consider using regular expressions for this). Create one Builder that puts the words into a java.util.TreeSet, and another that produces a java.util.HashMap containing words and occurrences of those words (that is, it does a word count).

Too many

Flyweight: too many objects

The odd thing about flyweight, in the company of the other design patterns, is that it’s a performance hack. It’s generally ideal to simply make an object for every item in your system, but some problems generate a prohibitive number of objects, which may result in excessive slowness or running out of memory.

Flyweight solves this problem by reducing the number of objects. To do this, you externalize some of the data in an object, so that you can pretend that you have more objects than you really do. However, this adds complexity to the interface for using such objects, because you must pass in additional information to method calls in order to tell the method how to find the externalized information.

As a very simple example, consider a DataPoint object that holds an int, a float, and an id that carries the object number. Suppose you need to create a million of these objects, and then manipulate them, like so:

Depending on your computer, this program may take several seconds to run. More complex objects and more involved operations may cause the overhead to become untenable. To solve the problem the DataPoint can be reduced from a million objects to one object by externalizing the data held in the DataPoint:

Since all the data is now in ExternalizedData, each call to a FlyPoint method must include the index into ExternalizedData. For consistency, and to remind the reader of the similarity with the implicit this pointer in method calls, the “this index” is passed in as the first argument.

Naturally, it’s worth repeating admonishments against premature optimization. “First make it work, then make it fast – if you have to.” Also, a profiler is the tool to use for discovering performance bottlenecks, not guesswork.

Decorator: too many classes

The use of layered objects to dynamically and transparently add responsibilities to individual objects is referred to as the decorator pattern.

#[BT_155]#Used when subclassing creates too many (& inflexible) classes

#[BT_156]#All decorators that wrap around the original object must have the same basic interface

#[BT_157]#Dynamic proxy/surrogate?

#[BT_158]#This accounts for the odd inheritance structure

#[BT_159]#Tradeoff: coding is more complicated when using decorators

Basic decorator structure

#[BT_160]#

A coffee example

#[BT_161]#Consider going down to the local coffee shop, BeanMeUp, for a coffee. There are typically many different drinks on offer -- espressos, lattes, teas, iced coffees, hot chocolate to name a few, as well as a number of extras (which cost extra too) such as whipped cream or an extra shot of espresso. You can also make certain changes to your drink at no extra cost, such as asking for decaf coffee instead of regular coffee.

#[BT_162]#Quite clearly if we are going to model all these drinks and combinations, there will be sizeable class diagrams. So for clarity we will only consider a subset of the coffees: Espresso, Espresso Con Panna, Café Late, Cappuccino and Café Mocha. We'll include 2 extras - whipped cream ("whipped") and an extra shot of espresso; and three changes - decaf, steamed milk ("wet") and foamed milk ("dry").

Class for each combination

#[BT_163]#One solution is to create an individual class for every combination. Each class describes the drink and is responsible for the cost etc. The resulting menu is huge, and a part of the class diagram would look something like this:

#[BT_164]#

#[BT_165]#Here is one of the combinations, a simple implementation of a Cappuccino:

#[BT_166]#

#[BT_167]#The key to using this method is to find the particular combination you want. So, once you've found the drink you would like, here is how you would use it, as shown in the CoffeeShop class in the following code:

#[BT_168]#

#[BT_169]#And here is the corresponding output:

#[BT_170]#

#[BT_171]#You can see that creating the particular combination you want is easy, since you are just creating an instance of a class. However, there are a number of problems with this approach. Firstly, the combinations are fixed statically so that any combination a customer may wish to order needs to be created up front. Secondly, the resulting menu is so huge that finding your particular combination is difficult and time consuming.

The decorator approach

#[BT_172]#Another approach would be to break the drinks down into the various components such as espresso and foamed milk, and then let the customer combine the components to describe a particular coffee.

#[BT_173]#In order to do this programmatically, we use the Decorator pattern. A Decorator adds responsibility to a component by wrapping it, but the Decorator conforms to the interface of the component it encloses, so the wrapping is transparent. Decorators can also be nested without the loss of this transparency.

#[BT_174]#

#[BT_175]#Methods invoked on the Decorator can in turn invoke methods in the component, and can of course perform processing before or after the invocation.

#[BT_176]#So if we added getTotalCost() and getDescription() methods to the DrinkComponent interface, an Espresso looks like this:

#[BT_177]#

#[BT_178]#You combine the components to create a drink as follows, as shown in the code below:

#[BT_179]#

#[BT_180]#This approach would certainly provide the most flexibility and the smallest menu. You have a small number of components to choose from, but assembling the description of the coffee then becomes rather arduous.

#[BT_181]#If you want to describe a plain cappuccino, you create it with

#[BT_182]#Creating a decaf Café Mocha with whipped cream requires an even longer description.

Compromise

#[BT_183]#The previous approach takes too long to describe a coffee. There will also be certain combinations that you will describe regularly, and it would be convenient to have a quick way of describing them.

#[BT_184]#The 3rd approach is a mixture of the first 2 approaches, and combines flexibility with ease of use. This compromise is achieved by creating a reasonably sized menu of basic selections, which would often work exactly as they are, but if you wanted to decorate them (whipped cream, decaf etc.) then you would use decorators to make the modifications. This is the type of menu you are presented with in most coffee shops.

#[BT_185]#

#[BT_186]#Here is how to create a basic selection, as well as a decorated selection:

#[BT_187]#

#[BT_188]#You can see that creating a basic selection is quick and easy, which makes sense since they will be described regularly. Describing a decorated drink is more work than when using a class per combination, but clearly less work than when only using decorators.

#[BT_189]#The final result is not too many classes, but not too many decorators either. Most of the time it's possible to get away without using any decorators at all, so we have the benefits of both approaches.

Other considerations

#[BT_190]#What happens if we decide to change the menu at a later stage, such as by adding a new type of drink? If we had used the class per combination approach, the effect of adding an extra such as syrup would be an exponential growth in the number of classes. However, the implications to the all decorator or compromise approaches are the same - one extra class is created.

#[BT_191]#How about the effect of changing the cost of steamed milk and foamed milk, when the price of milk goes up? Having a class for each combination means that you need to change a method in each class, and thus maintain many classes. By using decorators, maintenance is reduced by defining the logic in one place.

Exercises

             1.             Add a Syrup class to the decorator approach described above. Then create a Café Latte (you'll need to use steamed milk with an espresso) with syrup.

             2.             Repeat Exercise 1 for the compromise approach.

             3.             Create a simple decorator system that models the fact that some birds fly and some don’t, some swim and some don’t, and some do both.

             4.             Implement the decorator pattern to create a Pizza restaurant, which has a set menu of choices as well as the option to design your own pizza. Follow the compromise approach to create a menu consisting of a Margherita, Hawaiian, Regina, and Vegetarian pizzas, with toppings (decorators) of Garlic, Olives, Spinach, Avocado, Feta and Pepperdews. Create a Hawaiian pizza, as well as a Margherita decorated with Spinach, Feta, Pepperdews and Olives.

             5.             About Decorator, the Design Patterns book states: “With decorators, responsibilities can be added and removed at run-time simply by attaching and detaching them.” Implement the coffee decoration system to allow this “simple” detaching of a responsibility from the middle of the list of decorators of a complex coffee beverage.

#[BT_192]#

Connecting different types

Adapter

Adapter takes one type and produces an interface to some other type. #[BT_240]#When you’ve got this, and you need that, Adapter solves the problem. The only requirement is to produce a that, and there are a number of ways you can accomplish this adaptation.

#[BT_241]#

#[BT_242]#I’m taking liberties with the term “proxy” here, because in Design Patterns they assert that a proxy must have an identical interface with the object that it is a surrogate for. However, if you have the two words together: “proxy adapter,” it is perhaps more reasonable.

Bridge

While researching Bridge, I discovered that it appears to be the most poorly-described pattern in the GoF. I began to come to this conclusion when reading Alan Shalloway’s chapter on Bridge in his book Design Patterns Explained – he begins by pointing out that the description in GoF left him quite unenlightened.

At a conference, I talked to two people who had written about and were giving talks on design patterns, including Bridge. In two separate discussions I got completely different perspectives on the structure of Bridge.

Armed with misinformation, I delved back into the GoF and realized that neither of the above perspectives agreed with the book. I also found that the book did a miserable job of describing Bridge, except in one place – not the general structure chart describing the pattern, which wasn’t helpful, but in the structure chart describing their specific example. Only if you stare at that for a bit does Bridge begin to make sense.

An important feature to understand when looking at Bridge is that it is often a construct that is used to help you write code. You may choose the objects you use for a particular situation at compile-time or runtime, but the goal of Bridge is to allow you to structure your code so that you can easily add new kinds of front-end objects which are implemented with functionality in new kinds of back-end objects. Thus, both front-end and back-end can vary independently of each other.

The front-end classes can have completely different interfaces from each other, and typically do. What they have in common is that they can implement their functionality using facilities from any number of different back-end objects. The back-end objects also don’t have the same interface. The only thing the back-end objects must have in common is that they implement the same kind of functionality – for example, a group of different ways to implement a graphics library or a set of different data-storage solutions.

Bridge is really a code-organization tool that allows you to add in any number of new front-end services that implement their operations by delegating to any number of back-end options. Using Bridge, you can accomplish this without the normal combinatorial explosion of possibilities that would otherwise occur. But keep in mind that the vector of change with Bridge is typically happening at coding time: it keeps your code organized when you are dealing with an increasing number of options for implementing functionality.

Here’s an example whose sole purpose is to demonstrate the structure of Bridge (it implements the above diagram):

The front-end base class provides the operations used to fulfill the front-end derived classes, in terms of the methods of the back-end base class. Thus, any back-end derived class can be used to perform the operations needed by the front-end class. Notice that the bridging happens in this sequence of steps, each of which is providing a layer of abstraction. Here, Implementation is defined as an interface to emphasize that all the functionality is implemented in the back-end derived classes, and none in the back-end base.

The back-end derived classes perform the operations defined in the base class by delegating to objects (of class Library1 and Library2, in this case) that typically have radically different interfaces, but somehow provide the same functionality (this is one of the important objectives of Bridge). Effectively, each of the back-end implementations is an adapter to a different library or tool used to implement the desired functionality in a different way.

Exercises

             1.             Modify BridgeStructure.java so that the implementations are chosen using a factory.

             2.             Modify BridgeStructure.java to use delegation instead of inheritance on the front end. What benefits and drawbacks do you see by using delegation rather than inheritance?

             3.             Create an example of Bridge with an abstraction that is an associative array. This allows you to fetch elements by passing in a key Object. The constructor provides an initial set of key-value pairs which are placed in an array. As long as you only fetch elements, the array is used, but as soon as you set a new key-value pair, the implementation is switched to a map.

             4.             Use a bridge along with the collections in java.util.collections to create stack and queue classes using an ArrayList. After you get the system working, add a double-ended queue class. Now add a LinkedList as an implementation. These steps will demonstrate how Bridge allows you to add new front-end classes and new back-end classes in your code, with minimal impact.

             5.             Create a Bridge that provides a connection between various kinds of bookkeeping programs (along with their interfaces and data formats) and different banks (which provide different kinds of services and interfaces).

6.  

#[BT_250]#

#[BT_251]#

Flexible structure

Composite

The important thing here is that all elements in the part-whole have operations, and that performing an operation on a node/composite also performs that operation on any children of that node/composite. GoF includes implementation details of containment and visitation of children in the interface of the base class, but this doesn’t seem necessary. In the following example, the Composite class simply inherits ArrayList in order to gain its containment abilities.

While this approach seems to be “the simplest thing that could possibly work,” it’s possible that in a larger system problems could arise. However, it’s probably best to start with the simplest approach and change it only if the situation demands.

System decoupling

Observer

#[BT_383]#Like the other forms of callback, this contains a hook point where you can change code. The difference is in the observer’s completely dynamic nature. It is often used for the specific case of changes based on other object’s change of state, but is also the basis of event management. Anytime you want to decouple the source of the call from the called code in a completely dynamic way.

#[BT_384]#The observer pattern solves a fairly common problem: What if a group of objects needs to update themselves when some object changes state? This can be seen in the “model-view” aspect of Smalltalk’s MVC (model-view-controller), or the almost-equivalent “Document-View Architecture.” Suppose that you have some data (the “document”) and more than one view, say a plot and a textual view. When you change the data, the two views must know to update themselves, and that’s what the observer facilitates. It’s a common enough problem that its solution has been made a part of the standard java.util library.

#[BT_385]#There are two types of objects used to implement the observer pattern in Java. The Observable class keeps track of everybody who wants to be informed when a change happens, whether the “state” has changed or not. When someone says “OK, everybody should check and potentially update themselves,” the Observable class performs this task by calling the notifyObservers( ) method for each one on the list. The notifyObservers( ) method is part of the base class Observable.

#[BT_386]#There are actually two “things that change” in the observer pattern: the quantity of observing objects and the way an update occurs. That is, the observer pattern allows you to modify both of these without affecting the surrounding code.

#[BT_387]#-------------

#[BT_388]#Observer is an “interface” class that only has one member function, update( ). This function is called by the object that’s being observed, when that object decides its time to update all its observers. The arguments are optional; you could have an update( ) with no arguments and that would still fit the observer pattern; however this is more general—it allows the observed object to pass the object that caused the update (since an Observer may be registered with more than one observed object) and any extra information if that’s helpful, rather than forcing the Observer object to hunt around to see who is updating and to fetch any other information it needs.

#[BT_389]#The “observed object” that decides when and how to do the updating will be called the Observable.

#[BT_390]#Observable has a flag to indicate whether it’s been changed. In a simpler design, there would be no flag; if something happened, everyone would be notified. The flag allows you to wait, and only notify the Observers when you decide the time is right. Notice, however, that the control of the flag’s state is protected, so that only an inheritor can decide what constitutes a change, and not the end user of the resulting derived Observer class.

#[BT_391]#Most of the work is done in notifyObservers( ). If the changed flag has not been set, this does nothing. Otherwise, it first clears the changed flag so repeated calls to notifyObservers( ) won’t waste time. This is done before notifying the observers in case the calls to update( ) do anything that causes a change back to this Observable object. Then it moves through the set and calls back to the update( ) member function of each Observer.

#[BT_392]#At first it may appear that you can use an ordinary Observable object to manage the updates. But this doesn’t work; to get an effect, you must inherit from Observable and somewhere in your derived-class code call setChanged( ). This is the member function that sets the “changed” flag, which means that when you call notifyObservers( ) all of the observers will, in fact, get notified. Where you call setChanged( ) depends on the logic of your program.

Observing flowers

#[BT_393]#Here is an example of the observer pattern:

#[BT_394]#

#[BT_395]#The events of interest are that a Flower can open or close. Because of the use of the inner class idiom, both these events can be separately observable phenomena. OpenNotifier and CloseNotifier both inherit Observable, so they have access to setChanged( ) and can be handed to anything that needs an Observable.

#[BT_396]#The inner class idiom also comes in handy to define more than one kind of Observer, in Bee and Hummingbird, since both those classes may want to independently observe Flower openings and closings. Notice how the inner class idiom provides something that has most of the benefits of inheritance (the ability to access the private data in the outer class, for example) without the same restrictions.

#[BT_397]#In main( ), you can see one of the prime benefits of the observer pattern: the ability to change behavior at run time by dynamically registering and un-registering Observers with Observables.

#[BT_398]#If you study the code above you’ll see that OpenNotifier and CloseNotifier use the basic Observable interface. This means that you could inherit other completely different Observer classes; the only connection the Observers have with Flowers is the Observer interface.

A visual example of observers

#[BT_399]#The following example is similar to the ColorBoxes example from Chapter 14 in Thinking in Java, 2^nd Edition. Boxes are placed in a grid on the screen and each one is initialized to a random color. In addition, each box implements the Observer interface and is registered with an Observable object. When you click on a box, all of the other boxes are notified that a change has been made because the Observable object automatically calls each Observer object’s update( ) method. Inside this method, the box checks to see if it’s adjacent to the one that was clicked, and if so it changes its color to match the clicked box.

#[BT_400]#When you first look at the online documentation for Observable, it’s a bit confusing because it appears that you can use an ordinary Observable object to manage the updates. But this doesn’t work; try it—inside BoxObserver, create an Observable object instead of a BoxObservable object and see what happens: nothing. To get an effect, you must inherit from Observable and somewhere in your derived-class code call setChanged( ). This is the method that sets the “changed” flag, which means that when you call notifyObservers( ) all of the observers will, in fact, get notified. In the example above setChanged( ) is simply called within notifyObservers( ), but you could use any criterion you want to decide when to call setChanged( ).

#[BT_401]#BoxObserver contains a single Observable object called notifier, and every time an OCBox object is created, it is tied to notifier. In OCBox, whenever you click the mouse the notifyObservers( ) method is called, passing the clicked object in as an argument so that all the boxes receiving the message (in their update( ) method) know who was clicked and can decide whether to change themselves or not. Using a combination of code in notifyObservers( ) and update( ) you can work out some fairly complex schemes.

#[BT_402]#It might appear that the way the observers are notified must be frozen at compile time in the notifyObservers( ) method. However, if you look more closely at the code above you’ll see that the only place in BoxObserver or OCBox where you're aware that you’re working with a BoxObservable is at the point of creation of the Observable object—from then on everything uses the basic Observable interface. This means that you could inherit other Observable classes and swap them at run time if you want to change notification behavior then.

Mediator

Sweep coupling under the rug, how is this different from MVC?

MVC has distinct model and view; mediator could be anything. MVC a flavor of mediator

Exercises

             1.             Create a minimal Observer-Observable design in two classes. Just create the bare minimum in the two classes, then demonstrate your design by creating one Observable and many Observers, and cause the Observable to update the Observers.

             2.             Create a minimal Observer system using java.util.Timer inside your Observable, to generate events that are reported to the Observers. Create several different Observers using anonymous inner classes, register these with the Observable, and show that they are called when the Timer events occur.

             3.             Modify BoxObserver.java to turn it into a simple game. If any of the squares surrounding the one you clicked is part of a contiguous patch of the same color, then all the squares in that patch are changed to the color you clicked on. You can configure the game for competition between players or to keep track of the number of clicks that a single player uses to turn the field into a single color. You may also want to restrict a player's color to the first one that was chosen.

#[BT_403]#

#[BT_404]#

Reducing interface complexity

#[BT_239]#Sometimes the problem that you’re solving is as simple as “I don’t have the interface that I want.” Façade creates an interface to a set of classes, simply to provide a more comfortable way to deal with a library or bundle of resources.

Façade

#[BT_243]#A general principle that I apply when I’m casting about trying to mold requirements into a first-cut object is “If something is ugly, hide it inside an object.” This is basically what Façade accomplishes. If you have a rather confusing collection of classes and interactions that the client programmer doesn’t really need to see, then you can create an interface that is useful for the client programmer and that only presents what’s necessary.

#[BT_244]#Façade is often implemented as singleton abstract factory. Of course, you can easily get this effect by creating a class containing static factory methods:

#[BT_245]#

#[BT_246]#The example given in Design Patterns is just a class that uses the other classes.

A tax adviser is a Façade between you and the tax code, and a mediator between you and the tax system.A A

Package as a variation of Façade

#[BT_247]#To me, the Façade has a rather “procedural” (non-object-oriented) feel to it: you are just calling some functions to give you objects. And how different is it, really, from Abstract Factory? The point of Façade is to hide part of a library of classes (and their interactions) from the client programmer, to make the interface to that group of classes more digestible and easier to understand.

#[BT_248]#However, this is precisely what the packaging features in Java accomplish: outside of the library, you can only create and use public classes; all the non-public classes are only accessible within the package. It’s as if Façade is a built-in feature of Java.

#[BT_249]#To be fair, Design Patterns is written primarily for a C++ audience. Although C++ has namespaces to prevent clashes of globals and class names, this does not provide the class hiding mechanism that you get with non-public classes in Java. The majority of the time I think that Java packages will solve the Façade problem.

Algorithmic partitioning

Command: choosing the operation at run-time

#[BT_223]#In Advanced C++:Programming Styles And Idioms (Addison-Wesley, 1992), Jim Coplien coins the term functor which is an object whose sole purpose is to encapsulate a function (since “functor” has a meaning in mathematics, in this book I shall use the more explicit term function object). The point is to decouple the choice of function to be called from the site where that function is called.

#[BT_224]#This term is mentioned but not used in Design Patterns. However, the theme of the function object is repeated in a number of patterns in that book.

A Command is a function object in its purest sense: a method that’s an object[7]. By wrapping a method in an object, you can pass it to other methods or objects as a parameter, to tell them to perform this particular operation in the process of fulfilling your request. You could say that a Command is a messenger (because its intent and use is very straightforward) that carries behavior, rather than data.

#[BT_226]#

#[BT_227]#The primary point of Command is to allow you to hand a desired action to a method or object. In the above example, this provides a way to queue a set of actions to be performed collectively. In this case, it allows you to dynamically create new behavior, something you can normally only do by writing new code but in the above example could be done by interpreting a script (see the Interpreter pattern if what you need to do gets very complex).

#[BT_228]#Another example of Command is refactor:DirList.java [????]. The DirFilter class is the command object which contains its action in the method accept( ) that is passed to the list( ) method. The list( ) method determines what to include in its result by calling accept( ).

#[BT_229]#Design Patterns says that “Commands are an object-oriented replacement for callbacks[8].” However, I think that the word “back” is an essential part of the concept of callbacks. That is, I think a callback actually reaches back to the creator of the callback. On the other hand, with a Command object you typically just create it and hand it to some method or object, and are not otherwise connected over time to the Command object. That’s my take on it, anyway. Later in this book, I combine a group of design patterns under the heading of “callbacks.”

#[BT_230]#Strategy appears to be a family of Command classes, all inherited from the same base. But if you look at Command, you’ll see that it has the same structure: a hierarchy of function objects. The difference is in the way this hierarchy is used. As seen in refactor:DirList.java, you use Command to solve a particular problem—in that case, selecting files from a list. The “thing that stays the same” is the body of the method that’s being called, and the part that varies is isolated in the function object. I would hazard to say that Command provides flexibility while you’re writing the program, whereas Strategy’s flexibility is at run time. Nonetheless, it seems a rather fragile distinction.

Exercises

             4.             Use Command in Chapter 3, Exercise 1.

Chain of responsibility

Example: translation service (local->global->Babelfish).

#[BT_234]#Chain of Responsibility might be thought of as a dynamic generalization of recursion using Strategy objects. You make a call, and each Strategy in a linked sequence tries to satisfy the call. The process ends when one of the strategies is successful or the chain ends. In recursion, one method calls itself over and over until a termination condition is reached; with Chain of Responsibility, a method calls itself, which (by moving down the chain of Strategies) calls a different implementation of the method, etc., until a termination condition is reached. The termination condition is either the bottom of the chain is reached (in which case a default object is returned; you may or may not be able to provide a default result so you must be able to determine the success or failure of the chain) or one of the Strategies is successful.

#[BT_235]#Instead of calling a single method to satisfy a request, multiple methods in the chain have a chance to satisfy the request, so it has the flavor of an expert system. Since the chain is effectively a linked list, it can be dynamically created, so you could also think of it as a more general, dynamically-built switch statement.

In the GoF, there’s a fair amount of Thidiscussion of how to create the chain of responsibility as a linked list. However, when you look at the pattern it really shouldn’t matter how the chain is maintained; that’s an implementation detail. Since GoF was written before the Standard Template Library (STL) was incorporated into most C++ compilers, the reason for this is most likely (1) there was no list and thus they had to create one and (2) data structures are often taught as a fundamental skill in academia, and the idea that data structures should be standard tools available with the programming language may not have occurred to the GoF authors. I maintain that the implementation of Chain of Responsibility as a chain (specifically, a linked list) adds nothing to the solution and can just as easily be implemented using a standard Java List, as shown below. Furthermore, you’ll see that I’ve gone to some effort to separate the chain-management parts of the implementation from the various Strategies, so that the code can be more easily reused.

#[BT_236]#In StrategyPattern.java, above, what you probably want is to automatically find a solution. Chain of Responsibility provides a way to do this by chaining the Strategy objects together and providing a mechanism for them to automatically recurse through each one in the chain:

Exercises

             1.             Implement Chain of Responsibility to create an "expert system" that solves problems by successively trying one solution after another until one matches. You should be able to dynamically add solutions to the expert system. The test for solution should just be a string match, but when a solution fits, the expert system should return the appropriate type of ProblemSolver object. What other pattern/patterns show up here?

             2.             Implement Chain of Responsibility to create a language translator which begins by searching for a local specialized translation system (which may know specifics about your problem domain), then a more global generalized system, and finally falls back on BabelFish if it can’t translate everything. Note that each link in the chain may partially translate what it’s able to.

             3.             Implement Chain of Responsibility to create an tool to help reformat Java source code by trying multiple approaches to breaking lines. Note that normal code and comments will probably need to be treated differently, leading to the possibility of implementing a Tree of Responsibility. Also note the similarity between this approach and the Composite design pattern; perhaps the more general description of this technique is a Composite of Strategies.

#[BT_238]#

Externalizing object state

Memento

Use serialization to create an undo mechanism.

Complex interactions

Multiple dispatching

#[BT_405]#When dealing with multiple types which are interacting, a program can get particularly messy. For example, consider a system that parses and executes mathematical expressions. You want to be able to say Number + Number, Number * Number, etc., where Number is the base class for a family of numerical objects. But when you say a + b, and you don’t know the exact type of either a or b, so how can you get them to interact properly?

#[BT_406]#The answer starts with something you probably don’t think about: Java performs only single dispatching. That is, if you are performing an operation on more than one object whose type is unknown, Java can invoke the dynamic binding mechanism on only one of those types. This doesn’t solve the problem, so you end up detecting some types manually and effectively producing your own dynamic binding behavior.

#[BT_407]#The solution is called multiple dispatching. Remember that polymorphism can occur only via member function calls, so if you want double dispatching to occur, there must be two member function calls: the first to determine the first unknown type, and the second to determine the second unknown type. With multiple dispatching, you must have a polymorphic method call to determine each of the types. Generally, you’ll set up a configuration such that a single member function call produces more than one dynamic member function call and thus determines more than one type in the process. To get this effect, you need to work with more than one polymorphic method call: you’ll need one call for each dispatch. The methods in the following example are called compete( ) and eval( ), and are both members of the same type. (In this case there will be only two dispatches, which is referred to as double dispatching). If you are working with two different type hierarchies that are interacting, then you’ll have to have a polymorphic method call in each hierarchy.

#[BT_408]#Here’s an example of multiple dispatching:

#[BT_409]#

#[BT_410]#

Visitor, a type of multiple dispatching

#[BT_411]#The assumption is that you have a primary class hierarchy that is fixed; perhaps it’s from another vendor and you can’t make changes to that hierarchy. However, you’d like to add new polymorphic methods to that hierarchy, which means that normally you’d have to add something to the base class interface. So the dilemma is that you need to add methods to the base class, but you can’t touch the base class. How do you get around this?

#[BT_412]#The design pattern that solves this kind of problem is called a “visitor” (the final one in the Design Patterns book), and it builds on the double dispatching scheme shown in the last section.

#[BT_413]#The visitor pattern allows you to extend the interface of the primary type by creating a separate class hierarchy of type Visitor to virtualize the operations performed upon the primary type. The objects of the primary type simply “accept” the visitor, then call the visitor’s dynamically-bound member function.

#[BT_414]#

Exercises

             1.             Create a business-modeling environment with three types of Inhabitant: Dwarf (for engineers), Elf (for marketers) and Troll (for managers). Now create a class called Project that creates the different inhabitants and causes them to interact( ) with each other using multiple dispatching.

             2.             Modify the above example to make the interactions more detailed. Each Inhabitant can randomly produce a Weapon using getWeapon( ): a Dwarf uses Jargon or Play, an Elf uses InventFeature or SellImaginaryProduct, and a Troll uses Edict and Schedule. You must decide which weapons “win” and “lose” in each interaction (as in PaperScissorsRock.java). Add a battle( ) member function to Project that takes two Inhabitants and matches them against each other. Now create a meeting( ) member function for Project that creates groups of Dwarf, Elf and Manager and battles the groups against each other until only members of one group are left standing. These are the “winners.”

             3.             Modify PaperScissorsRock.java to replace the double dispatching with a table lookup. The easiest way to do this is to create a Map of Maps, with the key of each Map the class of each object. Then you can do the lookup by saying:
((Map)map.get(o1.getClass())).get(o2.getClass())
Notice how much easier it is to reconfigure the system. When is it more appropriate to use this approach vs. hard-coding the dynamic dispatches? Can you create a system that has the syntactic simplicity of use of the dynamic dispatch but uses a table lookup?

             4.             Modify Exercise 2 to use the table lookup technique described in Exercise 3.

#[BT_415]#

#[BT_416]#

Multiple languages

#[BT_256]#This chapter looks at the value of crossing language boundaries. It is often very advantageous to solve a problem using more than one programming language, rather than being arbitrarily stuck using a single language. As you’ll see in this chapter, a problem that is very difficult or tedious to solve in one language can often be solved quickly and easily in another. If you can combine the use of languages, you can create your product much more quickly and cheaply.

#[BT_257]#The most straightforward use of this idea is the Interpreter design pattern, which adds an interpreted language to your program to allow the end user to easily customize a solution. In Java, the easiest and most powerful way to do this is with Jython[9], an implementation of the Python language in pure Java byte codes.

#[BT_258]#Interpreter solves a particular problem – that of creating a scripting language for the user. But sometimes it’s just easier and faster to temporarily step into another language to solve a particular aspect of your problem. You’re not creating an interpreter, you’re just writing some code in another language. Again, Jython is a good example of this, but CORBA also allows you to cross language boundaries.

Interpreter motivation

#[BT_259]#If the application user needs greater run time flexibility, for example to create scripts describing the desired behavior of the system, you can use the Interpreter design pattern. Here, you create and embed a language interpreter into your program.

#[BT_260]#Remember that each design pattern allows one or more factors to change, so it’s important to first be aware of which factor is changing. Sometimes the end users of your application (rather than the programmers of that application) need complete flexibility in the way that they configure some aspect of the program. That is, they need to do some kind of simple programming. The interpreter pattern provides this flexibility by adding a language interpreter.

#[BT_261]#The problem is that developing your own language and building an interpreter is a time-consuming distraction from the process of developing your application. You must ask whether you want to finish writing your application or create a new language. The best solution is to reuse code: embed an interpreter that’s already been built and debugged for you. The Python language can be freely embedded into your for-profit application without signing any license agreement, paying royalties, or dealing with strings of any kind. There are basically no restrictions at all when you're using Python.

#[BT_262]#Python is a language that is very easy to learn, very logical to read and write, supports functions and objects, has a large set of available libraries, and runs on virtually every platform. You can download Python and learn more about it by going to www.Python.org.

#[BT_263]#For solving Java problems, we will look at a special version of Python called Jython. This is generated entirely in Java byte codes, so incorporating it into your application is quite simple, and it’s as portable as Java is. It has an extremely clean interface with Java: Java can call Python classes, and Python can call Java classes.

#[BT_264]#Python is designed with classes from the ground up and is a truly pure object oriented language (both C++ and Java violate purity in various ways). Python scales up so that you can create very big programs without losing control of the code.

#[BT_265]#To install Python, go to www.Python.org and follow the links and instructions. To install Jython, go to http://jython.sourceforge.net. The download is a .class file, which will run an installer when you execute it with Java. You also need to add jython.jar to your CLASSPATH. You can find further installation instructions at http://www.bruceeckel.com/TIPatterns/Building-Code.html.

Python overview

#[BT_266]#To get you started, here is a brief introduction for the experienced programmer (which is what you should be if you’re reading this book). You can refer to the full documentation at www.Python.org (especially the incredibly useful HTML page A Python Quick Reference), and also numerous books such as Learning Python by Mark Lutz and David Ascher (O’Reilly, 1999).

#[BT_267]#Python is often referred to as a scripting language, but scripting languages tend to be limiting, especially in the scope of the problems that they solve. Python, on the other hand, is a programming language that also supports scripting. It is marvelous for scripting, and you may find yourself replacing all your batch files, shell scripts, and simple programs with Python scripts. But it is far more than a scripting language.

#[BT_268]#Python is designed to be very clean to write and especially to read. You will find that it’s quite easy to read your own code long after you’ve written it, and also to read other people’s code. This is accomplished partially through clean, to-the-point syntax, but a major factor in code readability is indentation – scoping in Python is determined by indentation. For example:

#[BT_269]#The ‘#’ denotes a comment that goes until the end of the line, just like C++ and Java ‘//’ comments.

#[BT_270]#First notice that the basic syntax of Python is C-ish; notice the if statement. But in a C if, you would be required to use parentheses around the conditional, whereas they are not necessary in Python (but it won’t complain if you use them anyway).

#[BT_271]#The conditional clause ends with a colon, and this indicates that what follows will be a group of indented statements, which are the “then” part of the if statement. In this case, there is a “print” statement which sends the result to standard output, followed by an assignment to a variable named val. The subsequent statement is not indented so it is no longer part of the if. Indenting can nest to any level, just like curly braces in C++ or Java, but unlike those languages there is no option (and no argument) about where the braces are placed – the compiler forces everyone’s code to be formatted the same way, which is one of the main reasons for Python’s consistent readability.

#[BT_272]#Python normally has only one statement per line (you can put more by separating them with semicolons), thus no terminating semicolon is necessary. Even from the brief example above you can see that the language is designed to be as simple as possible, and yet still very readable.

Built-in containers

#[BT_273]#With languages like C++ and Java, containers are add-on libraries and not integral to the language. In Python, the essential nature of containers for programming is acknowledged by building them into the core of the language: both lists and associative arrays (a.k.a. maps, dictionaries, hash tables) are fundamental data types. This adds much to the elegance of the language.

#[BT_274]#In addition, the for statement automatically iterates through lists rather than just counting through a sequence of numbers. This makes a lot of sense when you think about it, since you’re almost always using a for loop to step through an array or a container. Python formalizes this by automatically making for use an iterator that works through a sequence. Here’s an example:

#[BT_275]#The first line creates a list. You can print the list and it will look exactly as you put it in (in contrast, remember that I had to create a special Arrays2 class in Thinking in Java, 2^nd Edition in order to print arrays in Java). Lists are like Java containers – you can add new elements to them (here, append( ) is used) and they will automatically resize themselves. The for statement creates an iterator x which takes on each value in the list.

#[BT_276]#You can create a list of numbers with the range( ) function, so if you really need to imitate C’s for, you can.

#[BT_277]#Notice that there aren’t any type declarations – the object names simply appear, and Python infers their type by the way that you use them. It’s as if Python is designed so that you only need to press the keys that absolutely must. You’ll find after you’ve worked with Python for a short while that you’ve been using up a lot of brain cycles parsing semicolons, curly braces, and all sorts of other extra verbiage that was demanded by your non-Python programming language but didn’t actually describe what your program was supposed to do.

Functions

#[BT_278]#To create a function in Python, you use the def keyword, followed by the function name and argument list, and a colon to begin the function body. Here is the first example turned into a function:

#[BT_279]#Notice there is no type information in the function signature – all it specifies is the name of the function and the argument identifiers, but no argument types or return types. Python is a weakly-typed language, which means it puts the minimum possible requirements on typing. For example, you could pass and return different types from the same function:

#[BT_280]#The only constraints on an object that is passed into the function are that the function can apply its operations to that object, but other than that, it doesn’t care. Here, the same function applies the ‘+’ operator to integers and strings:

#[BT_281]#When the operator ‘+’ is used with strings, it means concatenation (yes, Python supports operator overloading, and it does a nice job of it).

Strings

#[BT_282]#The above example also shows a little bit about Python string handling, which is the best of any language I’ve seen. You can use single or double quotes to represent strings, which is very nice because if you surround a string with double quotes, you can embed single quotes and vice versa:

#[BT_283]#Note that Python was not named after the snake, but rather the Monty Python comedy troupe, and so examples are virtually required to include Python-esque references.

#[BT_284]#The triple-quote syntax quotes everything, including newlines. This makes it particularly useful for doing things like generating web pages (Python is an especially good CGI language), since you can just triple-quote the entire page that you want without any other editing.

#[BT_285]#The ‘r’ right before a string means “raw,” which takes the backslashes literally so you don’t have to put in an extra backslash.

#[BT_286]#Substitution in strings is exceptionally easy, since Python uses C’s printf( ) substitution syntax, but for any string at all. You simply follow the string with a ‘%’ and the values to substitute:

#[BT_287]#As you can see in the second case, if you have more than one argument you surround them in parentheses (this forms a tuple, which is a list that cannot be modified).

#[BT_288]#All the formatting from printf( ) is available, including control over the number of decimal places and alignment. Python also has very sophisticated regular expressions.

Classes

#[BT_289]#Like everything else in Python, the definition of a class uses a minimum of additional syntax. You use the class keyword, and inside the body you use def to create methods. Here’s a simple class:

#[BT_290]#Both methods have “self” as their first argument. C++ and Java both have a hidden first argument in their class methods, which points to the object that the method was called for and can be accessed using the keyword this. Python methods also use a reference to the current object, but when you are defining a method you must explicitly specify the reference as the first argument. Traditionally, the reference is called self but you could use any identifier you want (if you do not use self you will probably confuse a lot of people, however). If you need to refer to fields in the object or other methods in the object, you must use self in the expression. However, when you call a method for an object as in x.show( ), you do not hand it the reference to the object – that is done for you.

#[BT_291]#Here, the first method is special, as is any identifier that begins and ends with double underscores. In this case, it defines the constructor, which is automatically called when the object is created, just like in C++ and Java. However, at the bottom of the example you can see that the creation of an object looks just like a function call using the class name. Python’s spare syntax makes you realize that the new keyword isn’t really necessary in C++ or Java, either.

#[BT_292]#All the code at the bottom is set off by an if clause, which checks to see if something called __name­__ is equivalent to __main__. Again, the double underscores indicate special names. The reason for the if is that any file can also be used as a library module within another program (modules are described shortly). In that case, you just want the classes defined, but you don’t want the code at the bottom of the file to be executed. This particular if statement is only true when you are running this file directly; that is, if you say on the command line:

#[BT_293]#However, if this file is imported as a module into another program, the __main__ code is not executed.

#[BT_294]#Something that’s a little surprising at first is that you define fields inside methods, and not outside of the methods like C++ or Java (if you create fields using the C++/Java style, they implicitly become static fields). To create an object field, you just name it – using self – inside of one of the methods (usually in the constructor, but not always), and space is created when that method is run. This seems a little strange coming from C++ or Java where you must decide ahead of time how much space your object is going to occupy, but it turns out to be a very flexible way to program.

Inheritance

#[BT_295]#Because Python is weakly typed, it doesn’t really care about interfaces – all it cares about is applying operations to objects (in fact, Java’s interface keyword would be wasted in Python). This means that inheritance in Python is different from inheritance in C++ or Java, where you often inherit simply to establish a common interface. In Python, the only reason you inherit is to inherit an implementation – to re-use the code in the base class.

#[BT_296]#If you’re going to inherit from a class, you must tell Python to bring that class into your new file. Python controls its name spaces as aggressively as Java does, and in a similar fashion (albeit with Python’s penchant for simplicity). Every time you create a file, you implicitly create a module (which is like a package in Java) with the same name as that file. Thus, no package keyword is needed in Python. When you want to use a module, you just say import and give the name of the module. Python searches the PYTHONPATH in the same way that Java searches the CLASSPATH (but for some reason, Python doesn’t have the same kinds of pitfalls as Java does) and reads in the file. To refer to any of the functions or classes within a module, you give the module name, a period, and the function or class name. If you don’t want the trouble of qualifying the name, you can say

#[BT_297]#from module import name(s)

#[BT_298]#Where “name(s)” can be a list of names separated by commas.

#[BT_299]#You inherit a class (or classes – Python supports multiple inheritance) by listing the name(s) of the class inside parentheses after the name of the inheriting class. Note that the Simple class, which resides in the file (and thus, module) named SimpleClass is brought into this new name space using an import statement:

#[BT_300]#Simple2 is inherited from Simple, and in the constructor, the base-class constructor is called. In display( ), showMsg( ) can be called as a method of self, but when calling the base-class version of the method you are overriding, you must fully qualify the name and pass self in as the first argument, as shown in the base-class constructor call. This can also be seen in the overridden version of show( ).

#[BT_301]#In __main__, you will see (when you run the program) that the base-class constructor is called. You can also see that the showMsg( ) method is available in the derived class, just as you would expect with inheritance.

#[BT_302]#The class Different also has a method named show( ), but this class is not derived from Simple. The f( ) method defined in __main__ demonstrates weak typing: all it cares about is that show( ) can be applied to obj, and it doesn’t have any other type requirements. You can see that f( ) can be applied equally to an object of a class derived from Simple and one that isn’t, without discrimination. If you’re a C++ programmer, you should see that the objective of the C++ template feature is exactly this: to provide weak typing in a strongly-typed language. Thus, in Python you automatically get the equivalent of templates – without having to learn that particularly difficult syntax and semantics.

Creating a language

#[BT_303]#It turns out to be remarkably simple to use Jython to create an interpreted language inside your application. Consider the greenhouse controller example from Chapter 8 of Thinking in Java, 2^nd edition. This is a situation where you want the end user – the person managing the greenhouse – to have configuration control over the system, and so a simple scripting language is the ideal solution.

#[BT_304]#To create the language, we’ll simply write a set of Python classes, and the constructor of each will add itself to a (static) master list. The common data and behavior will be factored into the base class Event. Each Event object will contain an action string (for simplicity – in reality, you’d have some sort of functionality) and a time when the event is supposed to run. The constructor initializes these fields, and then adds the new Event object to a static list called events (defining it in the class, but outside of any methods, is what makes it static):

#[BT_305]#The constructor of each derived class calls the base-class constructor, which adds the new object to the list. The run( ) function sorts the list, which automatically uses the __cmp__( ) method that was defined in Event to base comparisons on time only. In this example, it only prints out the list, but in the real system it would wait for the time of each event to come up and then run the event.

#[BT_306]#The __main__ section performs a simple test on the classes.

#[BT_307]#The above file is now a module that can be included in another Python program to define all the classes it contains. But instead of an ordinary Python program, let’s use Jython, inside of Java. This turns out to be remarkably simple: you import some Jython classes, create a PythonInterpreter object, and cause the Python files to be loaded:

#[BT_308]#

#[BT_309]#The PythonInterpreter object is a complete Python interpreter that accepts commands from the Java program. One of these commands is execfile( ), which tells it to execute all the st