View this PageEdit this PageAttachments to this PageHistory of this PageHomeRecent ChangesSearch the SwikiHelp Guide
Hotspots: Admin Pages | Turn-in Site |
Current Links: Cases Final Project Summer 2007

Fall 2004 Final Exam Review: Design Patterns

a. What are design patterns? How are they different from frameworks?
Design partterns are "codified standard practices of expert designers"(11-DesignPatterns.ppt). They are "a reusable implementation model or architecture that can be applied to solve a particular recurring class of problem"(Alpert et al).
Frameworks are "reusable design that describes how system in decomposed into objects." It is "a class library that captures interaction patterns between objects"(12-FrameworksDesign.ppt).

b. I am building a Word Processor and need to support unlimited undo of actions. What design pattern might I use to assist me in designing a good solution?

c. I am building a graphical user interface framework and need to subclass the window abstraction and the window implementation. What design pattern could I use?

d. I am limited to how many database connections I can have. What design pattern helps me limit the number of objects I can create?

e. I want to have several objects that "watch" another object and take action when the object changes. What design pattern will help?

a) They are different in that a design pattern is a cookie cutter design while a framework is a library that may (or may not) have been created using the design pattern. The framework can be used within another design pattern.

d) I am limited to how many database connections I can have. What design pattern helps me limit the number of objects I can create?

Singleton doesn't make sense to me. It's meant to exist as a Single object instance. A factory with some sort of limit on the number of creations might make more sense.

a worthwhile discussion of these questions can be found here:
we are looking for singleton on part d. -ellie

Why? That doesn't make sense. A Singleton is, by definition, a single instance. If the idea was to limit it to 1 instance, then it's completely understandable. However, even in the lecture slides, there's nothing about a number of objects (i.e. limited to say 5). It isn't a singleton if you have more than one. It might be a doubleton or a tripleton, but certainly not a singleton.

In the link you provided from a past semester: "have a class method that creates/returns an instance if the counter is less than the max number of objects and increments the counter." That's the definition of a factory! That's NOT a Singleton. I may be missing something, but in the information given to us in the slides and lecture, as well as past experience, this is NOT a Singleton (at least not the way the question is worded). That would completely defeat the purpose of the getInstance method of a Singleton considering you would be using the Factory pattern makeInstance.

It seems to me like this is rather a matter of judgement. Neither Singleton nor Factory Method can be applied drectly to the problem at hand in the form they were described in the patterns book. I will quote here the "Intent" section of both of these patterns:

Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses.

Ensure a class only has one instance, and provide a global point of access to it.

I got this just now from:
Design Patterns: Elements of Reusable Object-Oriented Software, Gamma et al, Addison-Wesley, 1995.

Therefore, clearly, we cannot apply either pattern without modification. Therefore, the real question is: do we want to say "Well, now instead of deciding which class to instantiate, our factory method will decide how many instances to make" or "Well, instead of being single, our singleton will be multiple, but with a fixed maximum number of instances". I would, personally, tend to lean to the former answer, but given the claim that the grading of the test will be flexible, I think both answers should be accepted as correct, given sufficient explanation and justification on the part of the student.

Link to this Page