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

Discussion 4 - Colin Gillens

My discussion will focus on a question from Midterm #1 Review - Spring 2004

Design Critique

What is wrong with the following and how do you fix it?

We decided to have one shape class and have a type attribtue which can be "Circle", "Rectangle", "Triagle". We have to case on the type to figure out what to draw. Later we need to case on the type again to output the postscript.

This presents the problem where new operations on a shape which will cause the shape to have to identify itself (using case statements) will always create more code within the class shape. A better design would involve inheritance where Shape would act as a super-class to the different types of shapes. The Shape class would contain all information and processes common to all shapes and the sub-classes or the shapes themselves, e.g., square, rectangle, triangle, etc... would independently contain processes which vary from shape to shape. An example of this would be the area in the case of different shapes.

Boxes need to use a pen so we had Box inherit from Pen.

If a box needs a pen, it should just make one for iteself to use. A box is not a pen and therefore should not inherit from Pen.

We got lots of coding done because we were able to copy code to many different classes.

If code can be copied from one method to another than a programmer might be experiencing a situation which could easily be resolved by breaking down methods into their component parts. If method C does what method A does plus a little of what method B does, then it should be written that way, one should not just copy and paste the code needed from methods A and B where appropriate.

We really only needed one "main" class and a couple of helper classes.

This may only be the case with a small and trivial program, but is generally not the case with a larger scale project. If one wishes to re-use any code developed objects should be abstracted from the classes and made independent. They may be tied together using a main but the objects themselves can function outside of the scope of the the main for that one program alone.

We call the class that edits the image part of the slide "EditBackground".

"EditBackground" does not describe and objects and therefore should not be a class. If one needs to preform the action of editing the background the appropriate object to perform that action should be identified and a function should be made to perform that action on demand. Only objects should be instantiable, not actions.

Link to this Page