Ken Webb 2010-02-26T22:53:52Z
Xholon uses some of the design patterns in the very popular 1995 Design Patterns book by Gamma, Helm, Johnson, and Vlissides. The book is often referred to as the Gang of Four (GoF) patterns book, because there are four authors. The use of these patterns in Xholon is sometimes intentional, but is more often just the way things turned out. This article describes some of the uses of these design patterns in Xholon. Xholon makes no attempt to use these patterns in the way described in the book, and the correspondences are quite loose. Xholon captures the spirit of many of these patterns without necessarily adhering to the details of the GoF pattern.
Contents |
The Xholon project and toolkit are based on composite structure as described in the Unified Modeling Language (UML) specification, and are closely aligned with the GoF Composite pattern. In GoF, Composite is a structural pattern, described as
Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly.
Most of the examples in GoF have to do with GUI and graphics applications, while in Xholon every object is intentionally part of a tree structure that represents a part-whole hierarchy. The name Xholon derives from holon which is an object that is both a whole and a part at the same time.
Composite seems to be the central pattern in GoF. It's one of the first patterns described in the book (p. 5). It has a central location in the overall diagram of design pattern relationships shown on the back inside cover (also on p.12) of the book, and has the most relationships (lines) with other patterns. Composite also has a pivotal role in the case study in chapter 2 of the book, where the authors state (p. 36)
A common way to represent hierarchically structured information is through a technique called recursive composition, which entails building increasingly complex elements out of simpler ones. Recursive composition gives us a way to compose a document out of simple graphical elements.
Represent an operation to be performed on the elements of an object structure. Visitor lets you define a new operation without changing the classes of the elements on which it operates.
New functionality can be easily added to nodes in a Xholon application, by using the built-in visit() method. Any object (the visitor) can visit any other object (a visitee) in the Xholon tree, passing itself in as a parameter. The entire subtree of the visited object will be invoked, and each node in that subtree will call back to the visitor. The visitor can take any action it wishes, possibly filtering its action based on the class of the visitee.
The visitor pattern is used a lot by Xholon scripts which can be pasted into a running Xholon application. A script typically attaches itself as the last child of the node into which it is pasted. It then calls visit() on its new parent node, which calls visit() on its first child, which calls visit() on its first child and next sibling, and so on recursively. The script usually removes itself from its parent once it has completed its action.
This can be used to restyle an entire subtree of widgets in a GUI, or to count the number of nodes in the subtree, or to rearrange the nodes in some way, or to renumber their IDs, or whatever. No additional code needs to be added to any of the visited nodes. All the new functionality is in the visiting script.
Encapsulate a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and support undoable operations.
Allow an object to alter its behavior when its internal state changes. The object will appear to change its class.
Many Xholon applications make use of state machines, based mostly on the UML specification for state machines.
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.
All services in Xholon are connected to each other by a chain of responsibility. When a client wants to locate a service, it passes the Service Locater Service (SLS) a string. The SLS gives each of its siblings (the objects in the chain) a chance to declare that they can handle services of the type identified by that string. The SLS invokes each service in the chain, starting with its next sibling, until it finds one that can handle that service, or until the chain runs out. Then it returns that service to the client, or it returns null if no such service exists.
Ensure a class only has one instance, and provide a global point of access to it.
Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically.