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

Sum2001 Midterm Review: Hotel Doors OOA/D

1.Use these:
Customer, LockCodeDatabase

Reject these hosers:
CentralLockDatabase - The name of this class implies that it
will have complete control over the database, with all
information contained therein. It would be a better design to
have a seperate class that holds a searchable collection of
encoded numbers.

CustomerWithMasterKey - this class implies a few things. First,
that there are two different classes for customers, and that
each type of customer class has a key built into it. A better
design would be to let Customers be a class by themselves, and
work out the key/master key difference in seperate classes that
the customer can have acces to.

2. Perhaps done later.

That's a fine line betweer CentralLockDatabase and LockCodeDatabase; actually, I don't quite see the distinction. What is the difference? On CustomerWithMasterKey, can you say more specifically why it's bad to have both CustomerWithMasterKey and CustomerWithoutMasterKey? (also, #2 is still open). -Lex Spoon

Well, the way I thought about the difference between the CentralLockDatabase and the LockCodeDatabase was that CentralLockDatabase would be a big powerful class that held in itself the collection of Lock codes and whatnot, whereas LockCodeDatabase might just be, by itself, a collection of LockCodes, with some accessing functionality provided by LockCodeDatabase. I dunno. I admit it's sketchy at best. Thinking about it over again, I would probably just put a Key class up there (and perhaps a MasterKey which would extend Key).

Having CustomerWithMasterKey and CustomerWithoutMasterKey would make it difficult to introduce different kinds of keys or different kinds of customers. If you wanted a kind of customer that could open all locks in section A (hypothetically), according tot his design, you would have to make CustomerWithKeyAccessToSectionA, which is not only annoying to type, but would also have to duplicate alot of the functionality of the other CustomerWith[.*]Key classes. If Mithras gave a hoot about OO, he would slay whomever committed this design error, since one of the main ideas of OO is to reduce duplication of implementations.

If you designed it right, it wouldn't have to duplicate a lot of functionality. Make a Customer base class, and subclass CustomerWith[] from that class. That's what OO is all about!

It's true that more kinds of keys will foul up the CustomerWith design, but that can be countered with arguments that there will "never" be any other kinds of keys. At any rate, there is a more serious problem with the CustomerWith classes.... But what? Any takers? And does anyone want to try #2? It's okay to add more than 2 classes, even though there are only 2 required. When I try #2, there are a few classes still missing. -Lex Spoon


Responsibities Collaborators
Have ID None

Responsibilities Collaborators
Open Door Key, Key Index

Key Index
Responsibilities Collaborators
Keep track of which key's
open which doors Lock

So this is where I am going with this.
Customer sticks "key" in door. Key has an ID that
Lock gets. Lock then goes to Key Index and says
"Does this key open me". Key Index simply replies yes
or no. There might need to be subclasses and stuff.
and Key Index might need to be broken into multiple parts.
Just my quick thoughts.
Hey it removed all the spacing I put in for formatting!!!!

Link to this Page