CSC/ECE 517 Summer 2008/wiki3 3 dm

Problem Description

Patterns Almanac. Peruse the Patterns Almanac for additional patterns that seem appropriate to cover in CSC/ECE 517. Explain why the patterns are appropriate for students to learn, and if possible, link to training materials (explanations, examples, etc.) for covering them. Your reviewers should rate your choices on how much value they will add to the course!

Pattern Definitions

1. Acyclical Vistor A more robust version of the more traditional visitor pattern, it defines operations to be performed on an object without adding them to the class itself or the class hierarchy. This can be useful if one needs to build handling or transformation functions that would otherwise not be a part of that class hierarchy. This visitor would be a valuable addition to our hierarchy as it becomes useful in any situation where the class contains information needed in a program but not in the form that is needed or otherwise needs to be operated. Avoids the dependency loops that can otherwise result in visitor or other rigid designs.
2. Command Processor A more complex version of the command pattern, it is defined by creating an object to encapsulate a request. It allows you to create parameters for the methods that go with the request, allow for customization based on the client. This pattern allows for scheduling requests and creating queues. This pattern can handle many different 'clients', creating a very versatile request and handling engine. A good example would be an object that handles request for locks or encryption.
3. Half-Object+Protocol A pattern that deals with multiple address spaces and the problems with getting information between them. Since you cannot have a single object that exists in more than 1 address space, you divide the object into two interdependent objects which use a protocol to communicate. This is a valuable pattern as its the basis of every type of distributed and internet structure, server/clients or even distributed nodes needing to communicate and being in separate address spaces.
4. Pipes and Filters A pattern dealing primarily with streams of data, something that is more and more common in days of feeds and streaming. By constructing a pipeline as your primary object and then applying filters to generate the correct objects at the other end are particularly useful. Pipes connect filters which are the abstraction on any data operation.
5. Wrapper Facade Based on the facade pattern, this pattern provides a robust object to encompass low-level data structures and operations. This is designed to make those structures easier to work with and provided additional functionality.
6. Gamma95:The approach that [Gamma95] takes is to use design patterns to raise the expressiveness and level of description in object-oriented programming. For [Gamma95] the patterns represent a way to increase reuse of object-oriented software. Once found, the experienced programmers reuse the good solutions again and again." Each design pattern systematically names, explains, and evaluates and important and recurring design in object-oriented system. " [Gamma95, p. 2]The two classification of patterns defined by [Gamma95] are purpose and scope. The purpose reflects what pattern does: Creational patterns such as Abstract Factory, Builder or Singleton involve in creation of objects; Structural patterns such as Adapter, Flyweight, or Proxy structure the object relations and composition; Behavioral patterns such as Iterator, Mediator, or Observer involve in object interactions.The scope specifies whether the pattern applies to classes or to objects. The relationships in class patterns are static and they define relationships between classes. Object patterns deal with dynamic object relationships which can change at run-time. The beauty and pain of object-oriented software is that the software code does not tell much about how the objects and their relationships behave in run-time. The dynamic behavior of well designed object oriented software makes software very flexible and difficult to understand. The design patterns help to divide and structure the software code so that the reusability and flexibility is maximized and the code is still understandable.
7. Buschmann96:Architectural patterns: We need to develop architectural patterns that can be reused across domains (e.g., banking, insurance, manufacturing) and across implementation strategies (e.g. CORBA, ActiveX/DCOM, Java ORBs). The pattern-oriented software architecture approach described by [Buschmann 96] provides a good foundation for architectural patterns.