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

Mark Nichols - Discussion 4

The following question is from Midterm #1 Review - Spring 2004

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.
  2. Boxes need to use a pen so we had Box inherit from Pen.
  3. We got lots of coding done because we were able to copy code to many different classes.
  4. We really only needed one "main" class and a couple of helper classes.
  5. We call the class that edits the image part of the slide "EditBackground".


Solutions

  1. One of the beauties of object oriented programming is that you do not have to use case statements. Instead of having one class with a type variable, you should create one class called Shape, and then create classes Circle, Rectangle, and Triangle. These will all be subclasses of Shape, and each of these objects can contain their own versions of the draw method for outputting postscript. Not only is this going to organize and clean up the coding process, but it is also much easier to extend to other shapes.
  2. A Box object is very different from a Pen object. It doesn't make sense that a Box would be a specialized version of a Pen. This is like saying a polar bear is a specialized form of a footbag. What you should do is simply use a Pen within the Box class as a local variable. For example, if the box needs the pen to draw itself, then perhaps in the draw method include something like
    |myPen| myPen := Pen new. 
    Then you can use the myPen instance of Pen to do what you need to get done.
  3. First off, the number of lines of code written is never a good indication of how much work you have completed. Secondly, copying code over and over is a good sign that you have a poor design. In this case, you can surely abstract some of the code you are reusing into a separate object. For example, if someone needed to keep track of time in several different classes, you could copy some time code you created into all of these, or you could simply use the TimeMorph object in each of the classes to take care of it. Abstraction is the key here.
  4. This is a huge problem. You cannot program in an object-oriented world in this way. The key to object oriented design is to make many objects that can relate to each other and hold methods specific to them. This helps everyone in the long run by making code more reusable and simpler. The "main" class can always be separated into components and sometimes those components can be abstracted further. One giant class is hard to read, not reusable, hard to test, and hard to debug.
  5. Objects are just that-Objects. "EditBackground" is an action, which should be a method. editBackground might serve better as a method of the Slide class. Not only have these people misnamed an object, but it seems that they have missed the purpose altogether. Alternatively, if editing the background is a large enough task to take an entire class, then it should be named something like BackgroundEditor which would have actions like "editBackground."

Links to this Page