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

Sum01 Final Exam Review: Whiz-O Toys

1) OO design helps to break the program into independent parts. A
programmer can then only be concerned with his portion of the
project. He will only have to consider the interfaces to the
other parts of the system- he will not have to understand how it
is implemented

2) if the interface to the simulated toy was the same as the interface to the real toy, it might be a simple as cutting and pasting the code.

3) OO helps enforce modular design, which would make additions easy.

Great idea for (2). For (1) and (3), though, everything there could be said any language with modules. What does OO bring to the table? Also, OO languages don't really force modularity–consider all the Java applets that consist of one huge class.... -Lex Spoon

"OO enable programmers to create modules that do not need to be changed when a new type of object is added. A programmer can simply create a new object that inherits many of its features from existing objects. This makes object-oriented programs easier to modify."

this could probably be said for both 1 and 3 right?


It helps a lot with #3, and a little with #1. How can OO help when the development team wants to work in independent parts? A lot of groups did this for the class project, for example – did OO have any help that a procedural language wouldn't? How?

Also, on #2, I just read the "cut and paste" part. There is an even better way than cut and paste to work with the scenario in problem #2.... -Lex Spoon

3. Each independent parts are easily tested and debugged. Integration is also much easier (putting together objects)?
2. Small pieces of the program can be built and test on prototype

1. OO makes it easier to explain exactly what is expected of a programmer. You can say "I want a robot that knows how to move forward, move backward, turn left, and talk," and maybe give the programmers a class with stubs for the requested functions. If you can stub out the entire project like this, it makes the possibility of communication errors much, much smaller.

2. Sure it could do that. Just replace the functions that operate directly on the virtual toy with functions that know how to interface with the actual toy.

3. Extend the old class to include the new functions, and you've got a new product where most of the code is reused from the old product.

Link to this Page