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

Sp02 Final Exam Review: Tradeoffs

A. What are the strengths and weaknesses of the Model-View-Controller structure for user interfaces? Give me an example of an application where MVC would really help, and another where MVC wouldn't help.

Some of the MVC strengths are that -
1) It separates the model and the view which results in a clean object-oriented structure.
2) It works well if you have to have multiple views which is based on the same model.
3) Easier to maintain???

Something where MVC would help - Customizing views on the model for any application where different users would have different levels of access. Example: Client Information in Banking. The manager would have almost all the information available, whereas, the accounts person would have only account info, the receptionist only contact info...and so on.

An application where MVC would not help too much would be something that is relatively small which could be done using VB, where maintainablity is not an issue. A standard address book application which is not too complicated.

Note: Even in the case mentioned above, MVC might be a better idea, but I dont know whether it would be worth the effort, since good MVC design is not the easiest thing to do. I wonder what Mark has to say about this?
MVC makes address books really easy. It makes hospital wards harder in some ways... Mark Guzdial

A bad place to use for MVC might also be in a low-bandwidth, low-computing capacity environment. I know, I know... buzzwords. Let's say we have a PDA using a low-powered wireless connection to interface to a large system. MVC might be had because the small pipe that the PDA has might not permit the excessive messages sent whenever even the tiniest updates happen.

B. What are the strengths and weaknesses of an object-oriented approach? Give me an example of a project where using OOA/D/P is the right idea, and an example where it's a bad idea.

Object-Oriented Strengths
1) Clear separation of data and behavior.
2) Allows for data hiding/ preferential access, ENCAPSULATION.
3) Robust, in that it is easily extendable through INHERITANCE.
4) Good OO programming means the code will be highly reusable.
5) Polymorphism.

1) Good object oriented design would mean a lot of classes. Dealing with these objects would probably result in slower speed.
Why? Why do more classes = slower speed? That's an interesting assumption – would make a good final exam question... Mark Guzdial

Create more classes, send more methods. Make your code as readable as possible. Trust in the compiler or vm for optimizations, and of course, faster hardware.
Hank Wilde

Are there any more?I could not think of any.

OOA/D/P would be great for a large system which is complicated but not very computationally intensive. A large payroll or sales and accounting system would surely be better written in an OO language.

When it comes down to pure number crunching and computationally intensive stuff such as scientific applications, a procedural language such as C would be a better choice.

OO is sliced bread when it comes to large projects that require abstraction, code reuse, and multiple programmers/teams of programmers working. But this is almost a language choices question. When we're closer to the hardware, as in, our every wish is the ARM processor's direct command, the benefit of abstracting hardware-level functions disappears when compared to the performance hit that the overhead of additional function calls adds. The hit may not be that great, but we're talking about hardware-level stuff. Those functions are _vital_ to the higher-level software (which is likely designed/implemented in OO, by the way :-)) and get consequently get called _a lot_. So the miniscule performance hit incurred in abstracting something like a screen draw to the video chip, when multiplied over the number of calls to the screen draw, adds up to quite a bit.

C. What are the strengths and weaknesses of Squeak vs. Java? Give me an example where using Squeak is a good idea and one where it's a bad idea, and one where Java is a good idea and one where it's a bad idea.

Squeak is better because it
1) is smaller and more portable
2) is simpler
3) has better multimedia support (not sure about this one)

Squeak loses out because it
1) is less secure
2) has poor thread support
3) is much slower
4) has less support
2 and 3 aren't obvious. Need a more refined answer. Mark Guzdial

Squeak is good for multimedia programming or writing VM's. One of the uses mentioned would be writing VM's for PDA's.
Squeak is not good where security is a factor.

Java would be great for large, network intensive applications. It would not be good for games and graphics as it is too slow.

Jai Kejriwal

So we come back to an issue we brought up earlier (in class): "What's the difference between Java and Squeak?" The main difference I see is that Java _loves_ the network. It's from Sun. They love the network to. Java has some built in functionality for transferring objects over the network (built-in object serialization) using RMI. I don't know of a similar technology in Squeak. This allows very flexible communication between clients and servers. Another advantage, enabled by RMI and other technologies, is Java can be used in parallel accross multiple machines, in a cluster. Squeak seems to be limited to running on one machine with no built-in support to go accross the network and "compare notes" with other machines running the app to see if they can make their job easier and do neat things like load balancing.

Link to this Page