Hotspots: Admin Pages | Turn-in Site |
Current Links: Case 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.
- Josh "The Key Master" Stephens
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.
- Josh "talks about religions he knows nothing about" Stephens
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
2.
Key
Responsibities Collaborators
Have ID None
Lock
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