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

Sp01 Final Exam Review: Tools for Space Scientists

See Final Exam Review - Sp2001

Comments? Answers? Criticisms?

a. The command design pattern would be very useful in this application. We are sure to have lots of menus, features, and actions that need to take place. However, a menu doesn't necesarily know which document will get the command (save, print, etc), but all the documents do have similar capabilities (even though they may be defined differently). With the Command Design Pattern, we can encapsulate a command as an object. Then the menu doesn't need to know what it's doing, it only knows it needs to execute some pre-defined command.
        Why is this good for our software
        UML Class Diagram:

_________________ ________________________
| UndoableCommand | | PluggableButtonMorph |
|—————–| |________________________|
| actionBlock | /\
| undoBlock | /__\
|—————–| |
| actionBlock: | |
| undoBlock: | _______|___________
| execute | 1 1 | PluggableMenuItem |
| undo |<-----------|-------------------|
|_________________|command | label |
/\ |——————-|
/__\ | onCommand: (class)|
| |___________________|
_____|_______ ______________
| SaveCommand | | Document |
|————-| 1 1|————–|
| |——–>| contents |
|————-| doc |————–|
| execute | | save |
| undo | |______________|

b. In general, Object Oriented Programming is good for:
Doug Powers

Undo is good to add, but there are a couple of patterns that this problem just screams out for. BTW, I agree with b-2, but "robust" isn't the word for that. Mark Guzdial

To quote from page six of the text: "The robustness comes from the fact that the loss of an object does not damage other objects, except for those that rely on the services or the roles of the lost object." If robustness isn't the word to describe that kind of stability then what is? Bryan Kennedy

Where can we find more information about all the design patterns covered in class? I have done so many searches and all the answers are vague, and the in-class notes went by too fast. Is there another reference you might know of (other than the Design Patterns book)?

Look in the NOTES/EXTRAS folder on the CD-ROM. Doug Powers

Imagine a solution in FORTRAN, and then in some OO language. What will be different about the two solutions? There is at least one very simple difference that is important. -Lex Spoon
Another big advantage of OO is encapsulation of data. In Squeak, for instance, by default all data is private and you can't accidentally change unless the object provides you with a modifier message.
Is the Observer pattern this design "screams for"?
I was thinking observer pattern also because you have a data set that is going to pretty much be shared among these documents yet each of these are quite different. Whenever the satellite's data changes in can update these. I was thinking a Factory Method is also a possibilty because these data would share many similarities in processing of data but can create own specifics of what exactly is done with the info.

can we get a concrete answer to this one? I've looked over the slides but I still am a little confused as to how these design patterns work and why you would want to use one over another Thanks

Link to this Page