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

Sp2001 Midterm Review: Design Critique

First of all, these statements seem very vague to say the least... the question asks for object oriented design analysis of these quotes, however not enough details are given in regards to what exactly we are evaluating here. I will attempt to give my view though.

(a) "Here are my CRC cards. This class here is named MapLinkedList and it is a collection of all the Map objects in the system..."

–I guess for this one you want us to point out that there are no
methods, variables or anything of that sort in this class and that
he needs to split up the different responsibilities of putting
these map objects into the collection between different
objects/classes... am I on the right track? I mean do you want us
to actually go ahead and design some other classes that can be
used to implement this type of problem.

(b) (6) "Here is my object ProcessMap. It knows its Map and it does the basic processing needed to get it on my website..."


–I don't even know where to start on this one... We didn't learn
about putting stuff on websites yet, so I don't see how we are
supposed to answer this question.

(c) (8) "But everything is controlled here by the MapManager object. No other object processes without confirming it with the MapManager."

–It's not a good idea to have every object check with one
particular object before processing? I'm confused...

Please point out exactly what we're analyzing here. Thanks

Arkady Shraybman

(a) isn't close. Think about analysis vs. implementation. For (b), think about "process" – isn't that a verb? (c) – you're on the right track, just keep going. Mark Guzdial


(a) The process of using technical terms such as linked list is a no-no for CRC cards since we are only analysing the problem and assigning different classes responsibilties. Also this design is not abstract enough. It does allow reusability of classes. In this case we could have a List class that contains a list of objects. In this way any object can be inserted into the List class if the need to do so arises.

(b) ProcessMap does too many things. It should delegate some of it's responsibilities to a Process class so that it can perform several processes one of which can be to put stuff up on a webpage. Also this ProcessObject class should act as a controller between the Process class and Object class such that any object can be assigned a bunch of processes and vice versa without each class having to know about the other, i.e, ProcessMap can be renamed ProcessObject. This class acts as a controller and contains a list of Process(es) and Objects(in this case Maps). So if in the future we had a different process for Maps(eg. collect all Maps of Australia) we don't have to reinvent the wheel, but add the new process to the ProcessObject class.

(c) It is not good for one class to control all processes in a design, since One class has too much information about all other classes. This could cause the program to be very inefficent when executed as everything has to go through a central class causing a potential bottleneck? —- Can't come up with a convincing explanation for this one :)

Bharath Hemachandran

A "Process" class? Exactly the wrong direction. Mark Guzdial

what's the correct answer? test coming up soon... ...
can somebody pls post the correct answer??? is this a trick qn or wat?


(a) CRC cards should simply analyze a situation and break it down into "responsibilities." A linked list is entirely too specific. There needs to be a more generic class that simply has the responsibility of keeping track of "all maps in the system," if that's the desired functionality. The fact that it's a linked list makes no difference at this stage.

(b) Aren't you supposed to think in terms of nouns? By using ProcessMap as a name, it's describing a function of the object, not what the object is itself. It's going against the very essence of OO design. A ProcessMap should not know its Map, but rather the other way around. There needs to be a Map class that is a Map. This Map can then have various messages that perhaps "process" itself. Of course, we're not really sure what "processing" a map means in this context, but it doesn't really matter. The flaw in the design is that an object should not be a verb but rather a noun.

(c) Not quite sure what this is talking about. All classes have to request permission from the MapManager to perform their action? Is that what this is saying? That would be rather useless. It's like setting up a nice OO design and then crumbling it down. If you're going to do that, you might as well just put everything in one class. :)


(c) The text specifically cautions not to have a "boss" object. In a system, the responsibilities should be distributed to make the programming tasks small and understandable, and to increase the robustness and reusability of the individual components. If they're all dependent on one Boss object to tell them what to do, then they're not all that robust.



Link to this Page