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

Sum02 Final Exam Review: OO Design Evaluation

Edit Sum02 Final Exam Review: OO Design Evaluation here.

1. this class is the main class and handles many of the tasks.

it's a god class. OO design is (in part) about decentralizing the flow of the program, so that messages are delegated to pieces of the software that are responsible for that particular flow of control. alan fay

2. we named the warehouse class ware because it is easier to type.

while not having anything to do with OO...

for the sake of clarity, classes should follow good naming conventions so their name is somehow indicative of their function and responsibility. alan fay
Actually OO also requires that the program is a simulation of the domain and the names should match those in the domain. Barbara Ericson

3. we are getting tons of code written because there are things we can just copy from similar classes.

the problem with copying code is that when one version of the code is altered, all the other copies must be updated, thus defeating the goal of higher maintainability through reusable components (yay for buzzwords!). the solution is found through inheiritance (when it makes sense) and/or through better delegating the responsibilities among the objects in the system. alan fay

4. we had one class inheirit from another because the one class needed to access some information in the other class, but we had a problem that some of the inheirited methods didn't make sense so we overrode them.

inheiritance should be done only when it makes sense to pass on methods from one class to another. if one class has data another class needs, just ask for it. send a message to the object requesting the data. alan fay
inheritance passes on both the methods and attributes. They should all apply to the child, not just a few. Barbara Ericson
When caught between inheritance and composition (i.e. delegation), use composition. (from Bruce Eckel's Thinking in Java) Jim Gruen

5. we have a type attribute in the payment class and then we case (switch) on the type to handle billing by credit card, purchase order, create a bill, etc.

instead of one payment class, consider subclasses of payment to respond to different forms of payment. for example, a CreditCardPayment class would handle the transaction of credit cards. alan fay

6. we had a guy who wanted to create about 10 classes but we found a way to do it in only 3!

it's difficult to say anything correct in reply to this. while as a general rule, more classes is indicative of a more thought-out system, this need not be the case. the real statement in there is the false perception of efficiency. let the compiler do it; let the interpreter figure it out. a major point of OO design is to make programs easier to mantain; write the code for people, write the compiler/interpreter for the machine. alan fay

7. we put most of the code into class methods and that way we don't need to create objects to do the work!

no point in using an OO language then, is there? alan fay
Code should only be placed into class methods when it makes sense – that is, the routine needs to affect an entire class of objects. Putting, say, a utility routine in a class method just so you don't have to create an object is poor design. When in doubt, put it in an instance method – the overhead's not so bad, and you can optimize later if necessary. ("Premature optimization is the bane of all programmers!") Think about it this way: What if you wrote a class method that made use of class variables, then tried to use that class in a multithreaded environment? You then run the risk of different threads calling your utility method at once, stomping all over each other's variables and wreaking all sorts of havoc. Jim Gruen

Link to this Page