CSC/ECE 517 Summer 2008/wiki3 2 acmoore2

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!

---

Design Patterns

Throughout the semester, the coursework has dedicated a lot of time to the discussion of Design Patterns. As stated by Christopher Alexander, in his book A Timeles Way of Building, a design pattern is a "solution to a problem in a context." Wikipedia defines software design patterns as follows:

In software engineering, a design pattern is a general reusable solution to a commonly
occurring problem in software design. A design pattern is not a finished design that can be
transformed directly into code. It is a description or template for how to solve a problem 
that can be used in many different situations. [http://en.wikipedia.org/wiki/Design_pattern_
computer_science)]

Most of the design patterns we have discussed in class were O-O design patterns. For example, during our lectures on Ruby we discussed several design patterns such as the Singleton[1], the Adapter Pattern[2], the Command Pattern[3], and the Strategy Pattern[4] to name a few.

The design patterns discussed were by no means a comprehensive list. The Patterns Almanac[5] is a resource for other design patterns that could potentially be included in future CSC 517 course lecture work. I have selected to discuss State Patterns[6], Basic Relationship Patterns[7] and the Manager Pattern[8]

---

State Patterns

The State Patterns listed in this section of Linda Risings Patterns Almanac where authored by P. Dyson, B. Anderson under the category 'Behavioral, Finite State Machines'. The patterns included in the State Patterns section are the Patterns State Object, State Member, Pure State, Exposed State, State-Driven Transitions, Owner-Driven Transitions and Pattern:Default State.

I thought that this would be an excellent candidate for a potential design pattern addition, especially to a course that discussed processes that could be encapsulated in state objects. The overall pattern tries to define a manner to efficiently handle changes of state, during runtime for example, tracking current state attributes and to try to delegate state-dependant behavior to the state object.

Other variations of the State Pattern are also discussed by Wikipedia[9] which also references implementing the design pattern with Finite State Machines[10].

---

Basic Relationship Patterns

The Basic Relationship Design Pattern narrows in on the design of any relationship between two objects in a program and how these objects can effectively and efficiently communicate and interact. This was authored by J. Noble in the Behavioral Category. The pattern is made up of a Relationship vs. Attribute Pattern, a Relationship Object, an Active Value Pattern and a Mutual Friends pattern.

I believe this is a viable design pattern for discussion because of the nature of programming that is continuously using relationships between object. To be able to have a design pattern to maximize understanding between programmers on how these relationships always work would be a vast improvement in the current programming standards.

There are many variations on this design pattern, one of which is the Active Record Relationship Design Pattern[11]. The discussion of this design pattern could be incorporated with our study of Ruby and design patterns.

---

Manager Pattern

The Manager Design Pattern listed by the Patterns Almanac is the final pattern that I think would be a great addition to the cirriculum. The Manager Designed Pattern was authored by P. Sommerland and the key aspect is that the management of each instance of a class is extracted from the object itself and designated to a Manager object. This allows for a much wider variation in functionality and for the reuse of Manager objects for a wide array of classes.

I have seen recently in a project I have worked on at work the implementation of this design pattern. It has led to a simplification of real-time job management where each job object is assigned to a manager to handle it's management operations. I think this would is an excellent design pattern and could use more exposure.

Just like I have experienced, EventHelix.com has implemented this design pattern in a realtime system.[12] www.cs.wustl.edu has put together a great presentation on the Manager Design Pattern as well. [13]

---

Conclusion

There was an incredible number of design patterns that were included in the Pattern Almanac and many of them are extremely effective, even though they are seldom discussed. I have tried to expose a couple of the design patterns I saw most relevant. The conclusion I have reached from my research is that design patterns are a crutial means of software development and design and can be used more than they currently are.

---

External References

[1] http://en.wikipedia.org/wiki/Design_pattern_(computer_science)

[2]http://en.wikipedia.org/wiki/Singleton_pattern

[3]http://en.wikipedia.org/wiki/Adapter_pattern

[4]http://en.wikipedia.org/wiki/Command_pattern

[5]http://en.wikipedia.org/wiki/Strategy_pattern

[6]http://www.smallmemory.com/almanac/

[7] http://www.smallmemory.com/almanac/DysonEtc98.html

[8] http://www.smallmemory.com/almanac/Noble99a.html

[9] http://www.smallmemory.com/almanac/Sommerlad98.html

[10] http://en.wikipedia.org/wiki/Finite_State_Machine

[11] http://synthesis.sbecker.net/articles/2006/01/19/active-record-relationship-design-patterns

[12] http://www.cs.wustl.edu/~schmidt/PLoP-96/sommerlad.ps.gz