Please feel free to forward this newsletter to as many friends as possible. I have a personal goal of having one million readers. I can achieve it with your help
the Software View: Quilting software from design patterns
Welcome back, gentle reader. Straight from the rumor mill, I heard this little tidbit. Microsoft is going to purchase the entire Whidbey Island, here in Washington state. Since it is already a Naval Air Station, Microsoft can have its own private airport. They can add private jets to the arsenal of shuttle vans that are currently scurrying around the Microsoft corporate campus. Numerous Microsoft senior executives live on Whidbey Island, and they are currently beginning construction for several golf courses.
For those of you with Internet and World Wide Web access and a Netscape Navigator web browser, please point your browser to:
http://www.softwareview.com/
Scroll down the page and you will spy a link entitled, "Current views web log (fresh news daily! Click reload, clear the browser cache)" The daily news page is also known as a "web log". It is en vogue and the fashion of these days to call it that. Click on the link, click "reload" on your browser or clear your browser cache to ensure that you always receive the freshest, hottest daily news concerning Java, Linux, XML, and the software industry! The link never changes, but I will be updating the HTML file page behind it every day. Please, do take a gander at it every day.
Also, some important news, gentle readers. the Software View is now an Associate Internet World Wide Web site of Amazon.com. I would like to extend my sincere, heartfelt gratitude and thanks for your patronage. I am offering links to books, et cetera that you can purchase from my web site. I would greatly appreciate it if you would purchase software industry books from my web site. Help support my newsletter and web site by purchasing items from Amazon.com from my web site. Here is the URL (Uniform Resource Locator):
Click here
Now, dear readers, on with this week's episode of the Software View!
The book, Design Patterns: Elements of Reusable Object-Oriented Software, was written by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. The authors are sometimes referred to as Gamma et. al., GOF, or GoF (Gang of Four). Design patterns are a pool of collective expertise that expert designers use in their designs. It is important to use design patterns to solve a problem, not to introduce complexity. There are elements of commonality to problems and design solutions to them.
It has been shown that all well designed object-oriented systems exploit recurring design structures that exhibit good abstraction, flexibility, modularity and elegance. Such design structures contain valuable design knowledge that needs to be remembered and reused. This idea has been formalized in terms of the idea of design patterns.
A design pattern captures a component of a complete design that has been seen experimentally to recur in solutions to problems and can be used not only to construct designs but also to communicate knowledge about these solutions. Design patterns can also be used as elements of a pattern language, which provides a way of communicating design level information, in the same kind of way that a programming language communicates code level information.
This is another boon for maintainability. If an application makes use of design patterns that are catalogued and known widely, it is much easier for a maintainer (who we presume is knowledgeable about design patterns) to comprehend the design of the system. This makes it easier for that person to make bug fixes or amendments to the program without violating the basic design and/or structure.
GoF writes, "Design patterns describe simple and elegant solutions to specific problems in object-oriented software design. Design patterns capture solutions that have developed and evolved over time. Hence they aren't the designs people tend to generate initially. They reflect untold redesign and recoding as developers have struggled for greater reuse and flexibility in their software. Design patterns capture these solutions in a succinct and easily applied form. Design patterns might take a little more work than ad hoc solutions. But the extra effort invariably pays dividends in increased flexibility and reusability.
All well-structured object-oriented architectures are full of patterns. Indeed, one of the ways to measure the quality of an object-oriented system is to judge whether or not its developers have paid careful attention to the common collaborations among its objects. Focusing on such mechanisms during a system's development can yield an architecture that is smaller, simpler, and far more understandable than if these patters are ignored. The importance of patterns in crafting complex systems has been long recognized in other disciplines."
Microsoft's COM (component object model) uses the Broker design pattern as its architectural construct. Clients do not access the server directly, but use proxies instead. Proxies have the same interface as the server objects. Thus, the client doesn't see any of the work necessary to manage the distributed communication. The server has a stub to match the client's proxy.
Mika Kujala writes, "Because of its full portability, clean object-oriented abstractions and a number of standard packages, JavaTM can readily be adopted as the implementation language for design pattern based solutions. The Java platform supports the design patterns principles very well, as it supports inheritance and interfaces. The Java interface/implementation model is extremely useful in a design patterns context."
The Chain of Responsibility pattern is a Behavioral design pattern. The intent of the Chain of Responsibility design pattern is to avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request. Chain the receiving objects and pass the request along the chain until an object handles it. Sun Microsystems' Java AWT (Abstract Window Toolkit or Abstract Windowing Toolkit) 1.0 old, containment-based event model adheres to the Chain of Responsibility design pattern. When the user acts on a Component -- clicking it or pressing the Return key, for example -- an Event object is created. The AWT event-handling system passes the Event up the Component hierarchy, giving each Component a chance to react to the event before the platform-dependent code that implements the Component fully processes it. Also, any calls to a Java class' super class adhere to the Chain of Responsibility design pattern.
The Command pattern is a Behavioral design pattern. The intent of the Command design pattern is to encapsulate a request as an object, thereby letting you parameterize clients with different requests. Sun Microsystems' Java adheres to the Command design pattern. Java supports method name overloading so that multiple methods can share the same name. For example, suppose you are writing a class that can render various types of data (strings, integers, and so on) to its drawing area. You need to write a method that knows how to render each data type. In other languages, you have to think of a new name for each method, for example, drawString, drawInteger, drawFloat, and so on. In Java, you can use the same name for all of the drawing methods but pass a different type of parameter to each method. So, in your data rendering class, you can declare three methods named draw, each of which takes a different type of parameter.
The Composite pattern is a Structural design pattern. The intent of the Composite design pattern is to compose objects into tree structures to represent part-whole hierarchies. The Composite design pattern lets clients treat individual objects and compositions of objects uniformly. Sun Microsystems' Java AWT containers adhere to the Composite design pattern.
The Strategy pattern is a Behavioral design pattern. The intent of the Strategy design pattern is to define a family of algorithms, encapsulate each one, and make them interchangeable. The Strategy design pattern lets the algorithm vary independently from clients that use it. Sun Microsystems' java.awt.LayoutManager interface and its subclasses adhere to the Strategy design pattern, in that they implement various strategies for laying out components in a container, and the strategy can be changed "on the fly" without changes to the containers (or the components). Sun Microsystems' java.awt.image.ColorModel class provides a uniform interface to handle different color models. It adheres to the Strategy design pattern, with each derived ColorModel class providing a different strategy for handling colors. The FocusManager in Sun Microsystems' java.awt.Window class also adheres to the Strategy design pattern.
The Abstract Factory pattern is a Creational design pattern. The intent of the Abstract Factory design pattern is to provide a facility for creating families of related or dependent objects without specifying their concrete classes. Sun Microsystems' java.awt.Toolkit class acts as an Abstract Factory for creating GUI (graphical user interface) specific components (AWT "peer" classes).
The Mediator pattern is a Behavioral design pattern. The intent of the Mediator design pattern is to define an object that encapsulates how a set of objects interact. The Mediator design pattern promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently. Sun Microsystems' java.awt.MediaTracker class (which manages the loading of graphical, audio, or other data) adheres to the Mediator design pattern controlling various sub-elements and making sure they function together. The FocusManager in Sun's java.awt.Window class also adheres to the Mediator design pattern.
The Bridge pattern is a Structural design pattern. The intent of the Bridge design pattern is to decouple an abstraction from its implementation so that the two can vary independently. Sun Microsystems' java.awt peer interfaces adhere to the Bridge design pattern and separate the actual implementations of the GUI elements from the "generic" interfaces.
The Singleton design pattern is a Creational design pattern. Sun Microsystems' Java class loader adheres to the Singleton design pattern. Its intent is to ensure a Java class has one and only one instance, and provide a global point of access to it. A singleton is a Java class for which only one instance can exist within a program. In other words, only one, single object of that particular class can be created in a program.
The MVC (Model/View/Controller) architecture separates a software component into three distinct pieces: a model, a view, and a controller. The Model/View/Controller architecture was introduced as part of the Smalltalk-80 version of the Smalltalk programming language (a popular object-oriented programming language invented by Alan Kay). The Model/View/Controller architecture reduces the programming effort required to build systems that made use of multiple, synchronized presentations of the same data. Its central characteristics are that the model, the controllers, and the views are treated as separate entities, and that changes made to the model should be reflected automatically in each of the views. The model is the piece that represents the state and low-level behavior of the component. The model can also represent data, as in a data model. It manages the state and conducts all transformations on that state. The model has no specific knowledge of either its controllers or its views. The system itself maintains links between model and views and notifies the views when the model changes state. The view is the piece that manages the visual display of the state represented by the model. A model can have more than one view. The controller is the piece that manages user interaction with the model. It provides the mechanism by which changes are made to the state of the model. This construction turns out to be a powerful design feature. It encourages reuse rather than redesign. While the MVC architecture is typically used for constructing entire user interfaces, the designers of the "Swing" graphical user interface components in Sun Microsystems' Java Foundation Classes 1.1 used it as the basis for each individual Swing user interface component. Each user interface component (whether a table, button, or scrollbar) has a model, a view, and a controller. Furthermore, the model, view, and controller pieces can change, even while the component is in use. The result is a user interface toolkit of almost unmatched flexibility.
The Iterator pattern is a Behavioral design pattern. It provides a way to access the elements of an aggregate object sequentially without exposing its underlying representation. Iterators provide an abstract mechanism to access elements in collection classes without revealing their underlying representations. Using this design pattern can help reduce code duplication and promote the degree to which software components depend on each other (coupling). The looser the coupling between components or subsystems the easy they are to interchange and maintain. A Java collection class is a class that can contain a number of items in a certain data structure such as linked lists and hash tables. An example of a Java collection class is Sun Microsystems' java.util.Vector. Sun's java.util.Enumeration interface also adheres to the Iterator design pattern. Hiding the underlying representation of a collection class helps reduce the level of coupling between classes. If used correctly, Iterators promote loose coupling between collection classes and their clients.
The Observer pattern is a Behavioral design pattern as well. Its intent is to define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically. Examples of the Observer design pattern can be found in the Smalltalk programming language's MVC (Model/View/Controller), Microsoft's C++ MFC (Microsoft foundation classes) document/view architecture, and Sun Microsystems' java.util.Observable class. Sun's java.util.EventListener interface, which is part of Sun's JavaBeans component architecture, also adheres to the Observer design pattern. The Observer design pattern generally is used to inform clients (Observers) if the state of an object (known as the subject) that they have expressed an interest in changes. The Observer design pattern has two participants, Observers and Observables and defines a one to many relationship between them. An Observerable object contains a list of its Observers. When the Observable's state changes it notifies its Observers so that they are updated automatically. Observers can help reduce code duplication and promote the degree to which software components depend on each other (coupling). The looser the coupling between components or subsystems the easy they are to interchange and maintain. Sun's java.awt.image.ImageObserver interface also adheres to the Observer design pattern.
The object-oriented design of Java supports the use of design patterns, since design patterns are heavily based on objects and their collaborations. Participants of design patterns are usually objects (or objects take the role of possibly several participants). Java objects can thus take the role of a participant such as the client of a Composite design pattern. Sun Microsystems' Java interfaces certainly are good tools for design patterns. Objects that participate in several patterns in different roles can easily be designed using Sun's Java interface definitions.
Comments in reply to this episode by Krishnan Sundararaman
Sincerely,
Mark Kuharich
Join my free e-mail newsletter called the Software View by clicking here or sending mail to thesoftwareview-owner@west-point.org