Hotspots: Admin Pages | Turn-in Site |
Current Links: Cases Final Project Summer 2007
Discussion 4 #2
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".
1. The problem here is that the relationship between shape and "circle", "rectangle", and "triangle" is an "is-a" relationship. Therefore, circle, rectangle, and triangle should inherit from shape, and not be attributes of shape. This makes more sense and allows polymorphic handling instead of type testing. This also allows for easier extension. Both of which are staples of good design.
2. Again, the problem here is an incorrect implementation of the type of relationship between Pen and Box. Boxes need to have access to a pen for drawing, so the relationship falls under the "uses-a" or "has-a" type. This means that Pen should be a member in the Box class, and that Box should not be a subclass of Pen. It helps to think of the real life objects you're modeling in this case. When doing so, the relationship is easier to categorize.
3. Copying and pasting code to many different classes is a tell-tale sign of poor design. It fails to achieve the reuse of code, which is one of the goals of good design. Luckily, this is an easy problem to fix. Most of the time, this problem can be solved by abstracting out the duplicated code into a different method or object, then have the places where the duplicated code originally was use the new method or object. This way code is reused, and thus the design is better. Also, if the duplicated code had bugs, it is easier to fix in one location than to search through every duplication to fix things.
4. Having one main "manager" class is another tell-tale sign of poor design. It is poor becuase it is hard to reuse and doesn't correspond to an object. If you run into this situation, it's best to take a step back and review your design as a whole. The solution will involve breaking the "manager" class into seperate classes, each that abstract out certain parts. The smaller classes provide for more reuse and better overall design than a manager class.
5. Naming a class "editBackground" is poor design because, not only is it misleading, it doesn't correspond to an object. In any case, "editBackground" sounds much more like a name of a method (i.e. an action, not a thing). So, to fix this problem, change the name of the class to a noun-type name, as opposed to a verb. editBackground can be used for a method name; in that role it is descriptive and appropriate. All classes should have noun-type names. Methods should have verb-type names.
Link to this Page