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

Sp00 Final Exam Review: Tradeoffs

See Final Exam Review - Sp2000

a)
MVC strengths:

MVC weaknesses:

MVC would really help if you want to have a single model keeping some state and data, and many people need to see and manipulate it. Something like a scheduling system where a lot of different people need to see a schedule, change it, etc. But, there is just one underlying calender of events that everyone messes with.

MVC would be really bad if you had many different models of some state and many views for these states. An example would be a hospital with the patients being the model. There are MANY patients in a hospital, and a lot of different parts of the hospital must keep track of them and their state ( dead/alive, OR times, heart beat, etc... ). With this scenario, you have many models and many views. This can get quite complex and convoluded, especially if it has to be extensible and robust. Maintenance would be a nightmare
Would it be easier without MVC? Mark Guzdial

b)
OO approach strengths:

OO approach weaknesses:

What do you mean by big, clunky? Mark Guzdial

Outside of C++ which has execution speed near that of C w/out virtual functions, when one decides on an OO language, there is an inherit overhead in dealing with objects as compared to procedural languages -Stephen Belknap
Squeak's object structure consists of 1 word of header. "Big, clunky" Well, okay... Mark Guzdial
what about the boxing/unboxing overhead for primitives? Does that not play a big role in the speed? I know it's an overhead for the primitive itself, but I don't know how it affects the overall performaince in the Big Picture -Stephen Belknap

You'd want to do the whole OOA/D/P in a banking system. You would need to have a lot of information hiding, encapsulation, and security. OO could provide these necessary services easier than a nonOO approach.

You wouldn't want to use OO when you want a brute-force computational fast application. Possibly some math program or physics program that really could run quickly, and wouldn't need the OO-given benefits.

Note to others: This ain't the whole story. It's okay, but there's more. Mark Guzdial
c)
Squeak Strengths compared to JAVA :

Squeak Weakness compared to JAVA :

Squeak would be a good idea if you wanted to do some educational software b/c Morphic and Wonderland is nice to mess around with, and it could provide a great visual tool Squeak would not be a good idea for some wireless networking b/c it isn't fast enough.

Java would be great to do highlevel non-wireless networking. It provides great cross-platform support.
Java would not be a great choice for a game where frame rate is key, like an FPS Doom-like game.



Could you reformat those Squeak vs. Java lists? "Squeak vs. Java Strengths" doesn't tell me what the strengths are of. Squeak? Java? The comparison? Mark Guzdial
Cool, thanks. These are reasonable (though I'd disagree that Squeak's exception support is "better"), but certainly others are possible. Mark Guzdial
Better in the fact that, in Java, if you get an exception, you try and find the handler in the current frame, and keep popping off frames until you either find a handler, or are in main(), in which case you probably have a famous NullPointerException. But in Squeak, you can have the option of continuing: correcting the problem that raised the exception, and having some sort of re-do logic that continues where it previously died. -Stephen Belknap


b) The strengths of OOD is that it supports reuse very well. It is also great for teams working on a project together. Each person can do one class and when the whole program is put together it will work. (This will only happen if it is a good design, though). Weaknesses are that it is a slow process and it is hard to do well.
OOA is good for a very large program, such as an interface for a legacy system. It is bad for a small program that you want to throw away after a few uses.

Susi Rathmann, jeremy, Matt Flagg

Comments on part B:
In general, OO is more conducive to applications programming and procedural languages are more conducive to low level systems programming (especially when memory/speed constraints are tight). I could elaborate forever on this question.

Stephen Bennett

Link to this Page