Hotspots: Admin Pages | Turn-in Site |
Current Links: Case Final Project Summer 2007
Sp2002 Midterm Review: Design Critique
Back to Spring 2002 Midterm Review
Comments/answers/critiques?
1. You don't want class names to define the method of implementation. In this case you don't want LinkedList as part of the class name, what if you decided later to put your list of maps into a dictionary?
2. Classes should be nouns, not verbs. You could have a class called MapProcessor that has a method called processMap.
3. MapManager sounds like a "God" class, which is bad because it requires every part of the system to rely on a single class. This makes code that cannot be reused
Bill Branan
1. Calling it MapLinkedList is way to low-level for CRC cards.
3. It also sounds like the Map classes must know about their MapManager, which is bad design. Maps should not necessarily need a Manager of any kind.
#19
2. Processing the map is done by a method or set of methods. It doesn't have to be stuffed into one class. Maybe map processing can be broken down into even smaller, more reusable pieces instead of lumping it all together.
Marco Rogers
- breaking down processMap could work if the individual subcomponents are usable by themselves, but designing your objects around methods sounds like functional programming fever. The person appears like they are thinking along the lines of functions and not real objects, so breaking it down could be your same mistake— Watch out - where is a good place for processMap (think responsibilities)? Webb
Yeah I don't think the above was very clear at all. As far as processMap goes why does it have to know it's Map? It seems to me that you could have a generic class that will take in and process whatever map you give it. In the above implementation wouldn't you have to have a separate instance of processMap for each map in your list?
Marco Rogers
Link to this Page