Sp01 Final Exam Review: Tools for Space Scientists

Hotspots: Admin Pages | Turn-in Site |
Current Links: Case 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

Scientist may be "book smart" but they're often absent minded and make dumb mistakes. Thus, it would be good if they had an undo feature. This is easy to do with the Command Design Pattern. We simply keep a stack (as in the data structure) of executed commands and if the user clicks 'undo' the top Command is popped off the stack and is told to undo itself.
If a scientist finds himself doing something over and over again, he can combine a series of steps and create a macro. From a backend standpoint, the macro would consist of nothing more than a list of commands to execute in order.

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:

It is easy to build complex systems that are still easy to maintain if the system is made up of a lot of small objects that are easy to maintain. We can easily support more documents by just adding more subclass of ScientificDocument, etc.
Object Oriented Programs are robust. If one object fails or changes, it shouldn't effect anyone else (at most, only those that directly collaborate with it). If the way data is loaded into the system is changed, we won't have to change the code in our 2D and 3D graph objects– they only need a predefined way of obtaining information from another document.
OO Programming allows for reuse. All the documents in our system will share some functionality (like saving, loading, printing ,ect). By using inheritance, we can have all our documents support the same functionality while reusing the same code for each object unless a document has some special feature that requires a method to be overwritten.

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)?

jehan

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"?

Dmitri

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.

Ali

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

Final Exam Review - Sp2001 last edited on 20 April 2001 at 1:29 pm by user-vcauj11.dsl.mindspring.com.