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 - Chris Ronderos

Chris Ronderos
Discussion 4 Choice 1

Design Critique Question from Summer 2003 Midterm Review

Design Critique

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

  1. 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 design does not use encapsulation. It neglects all the great aspects of Object Oriented software. The correct way to do this would be to use three objects named Circle, Rectangle, and Triangle, that extend a common parent in the abstract class Shape. Shape defines that shapes must have draw and output to postscript methods, but does not implement them. The actual shape classes, Circle Rectangle and Triangle, each implements their own separately. This way, relevant data and methods are encapsulated. Circle knows how to draw himself and how to output himself to postscript. This solution also leverages Inheiritance and Polymorphism when it comes time to use the objects. Since they all inheiret from Shape, they all have Shape's methods and variables. They can pass off as Shapes. So a method can want a Shape, and be passed a Circle as a valid input with Polymorphism. Then, through Dynamic Binding, the Circle's methods are called by the method, instead of the parent class's methods.

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

    Box should not inheirit from Pen just because it needs to use a pen. Box could very well need to use other classes, but it can not inheiret from all of them. Instead, Box needs to have access to his own instance of pen to use. Box can then delegate to pen the jobs he needs it to do, without being a pen himself.

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

    Copying lots of code around is a bad idea. If it needs to be changed, suddenly it has to be changed in many places. If a large block of code is being copied around, it should be brought out in some way, into its own method or class (depending on the circumstance). That way, other objects can delegate to it a certain job, but it is a central point so that it can be edited easily.

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

    This "main" class quickly becomes impossible to manage. Instead, various objects should be designed that interact with each other. Each should know only about itself, and how to interact when given other objects with certain messages. Using this, a collection of easy to understand and easy to manage and edit objects can do the same job as a "god" class with much less work on the part of the software engineer.

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

    This is a bad name. The class that edits the image part should be "ImageEditor". Names are important in OO programming. First of all, they should be nouns. The name This is the first clue to others who could want to reuse the code in the future as to what exactly this class does. Naming classes well also makes code much easier to read (and, therefor, to manage) as a programmer can read code and find it "self documenting", so he can see exactly what it does. And when programmers can look at code, and see what it does, they can edit it with less work understanding it first.

Links to this Page