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. The discussion of this design pattern could be incorporated with our study of Ruby and design patterns.

---

Manager Pattern

---

Conclusion

---

External References

[11]

[12]

[13]

[14]

[15] to name a few.

[16]

[17]

[18]

[19]