CSC/ECE 517 Summer 2008/wiki3 3 dm

Topic 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!

Introduction

In CSC/ECE 517 we cover a number of basic design patterns in an effort to aid our coding development. Design Patterns like most intellectual processes provide a framework for thought, getting you to think of components and polymorphism. By examining the problem and deciding which pattern fits it most closely, we create a basic framework for the program to be constructed from. A factory pattern dedicates certain components and behaves in a certain manner, so using it for an application implies both structure and function.

However we only cover a small number of the possible patterns, with many of them being either too simplistic to be encompassing or providing the necessary structure for the sort of programming we are likely to need to perform in the work force. While they provide a basic tool box, but that isn't going to sufficient for wielding or electrician's work. So we need more complex patterns to deal with much more likely scenarios.

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. Avoids the dependency loops that can otherwise result in visitor or other rigid designs. This pattern is our default pattern for discussing functions or even classes that we can't fit into a design or to add necessary functionality. So this is your go to pattern when your boss requires additional functionality that your object structure can't handle or you need add a handler/converter function for an object that doesn't fit into your object structure or increase the complexity to unacceptable degrees.
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. Presentation-Abstraction-Controller It defines a structure for interactive software systems in the form of a hierarchy of cooperating agents.Every agent is responsible for a specific aspect of the application’s functionality and consists of three components: presentation, abstraction and control.

Conclusions

Overall, each of these patterns provide a more descriptive and more focused scenario. Each of these design patterns are less likely to appropriate for a given program, as they have more specific requires. But in return they provide much greater detail or deal with problems that the other patterns cannot properly cope with. These select few are examples that will likely be much more common in the future, in both distributed and internet development.

Related Links

1. http://c2.com/cgi/wiki?AcyclicVisitor
2. http://web.ist.utl.pt/rito.silva/mdo/papers/Kobryn.html
3. http://www.automationit.hut.fi/julkaisut/documents/seminars/sem_s02/Honkanen_paper.pdf
4. http://www.smallmemory.com/almanac/Schmidt99.html
5. http://www.smallmemory.com/almanac/Meunier95.html
6. http://www.smallmemory.com/almanac/Martin98.html
7. http://www.smallmemory.com/almanac/Sommerlad96.html