View this PageEdit this PageAttachments to this PageHistory of this PageHomeRecent ChangesSearch the SwikiHelp Guide
Hotspots: Admin Pages | Turn-in Site |
Current Links: Case Final Project Summer 2007

Fall2001 Midterm Review: Hotel Doors OOA/D

Link back to Fall 2001 Midterm Review

1. The two classes that I would need to design this system would be a Lock class for impeding entry to the room and a LockDataBase class that would store the valid keys for each lock and associate them with the appropriate lock or locks. I might consider implementing a class for a Door and a class for a Hotel. The reason for not implementing the door class or the hotel class is for the level of complexity required to implement the system does include doors and hotels. They are general enough for situations that use different doors or are implemented in centers that are not hotels.

I would like to make a point on the usage of a Key class. I am not sure if the question implies the Key class as one of the classes to not implement, but I think that it is useful. The key contains the information that is required to unlock the lock. In all systems that implement the lock and key approach, the key's information is gathered by the lock and tested. A physical lock determines the state of the key. The state of the key contains the information to unlock the lock. In cyberspace, the key has a state, which is held in bits. The state contains the information required to unlock the cyber lock. In all key and lock systems, something contains the information for unlocking the lock. That something is a key. There should be a common interface for locks and keys. The key should be able to pass the information that is stored in its state. Therefore, if only for abstractoin, a Key class should be created and a method, retrieveInformation, should be implemented.
Christopher Henke

There's a saying in the OOA/D literature: "You can never have too many classes." Why are you trying to limit the number of classes you define, Christopher? Mark Guzdial
I'm just saying that the system can be more generic and perform the same functionality required for the Hotel situation. For instance, let's say that I wanted to add a fully armed quad pro super laser mounter five to bar entry. I don't have to have a door or Hotel. And if I wanted to reuse my system for this example I would have to change the code for the lock to change the door to a laser and the code for the whole system from a Hotel class to a Military Installation class. I don't want to rewrite the code required for implementing basic functionality of the system. I want seperated modules that interface together and are interchangable. I want abstract objects at first. A lock is an abstract concept. A database is an abstract concept. A key is an abstract concept. A door, in my opinion, is not abstract enough. It shouldn't matter that it's a door that impedes entry or exit. It doesn't matter where the system resides. What these two concepts are required for are specific instantiations of a security system. The more general setup for the security system is more abstract.

Since there are multiple ways to instantiate the system that all share common attributes, the abstract system should contain those attributes for setting of them on the instantiation. A door has a more abstract class of obstruction, or even more abstract class of deterrent. A hotel is a location. Therefore, the classes Deterrent and Location should be implemented with Hotel and Door as their respective subclasses, or better yet their names (have no Hotel or Door classes).
Christopher Henke

As for the Key class would this class be bad design. I personally think that creating one has alot of benefits, but in class Guzdial said that a class should have both data which it contains as well as responsibilities that it must proform. It seems as if the only methods which are written to Key is get/set. Show would this be an example of a class which we would want to reject, even though it helps us model the real world?
Robert Schierholz
I think that a key class would be a great idea. It provides for future felxibility. Say you suddenly want to encrypt all of your key cards. Without a Key class you would have to add decrypting messages into the Lock class. That would be a viable solution but I think it would be better design to have the Key decrypt itself. Jared Parsons

I don't think it would be good design for the key to decrypt itself. This seems like it would open up security problems as well as be outside the responsibilities of the key. Say I have a regular key, when I put it in the lock, it's not the key's responsibility to make the tumblers fall in place correctly. Furthermore, if I can't get into a door with my key, I call maintenance and they fix the lock, not my key. Even in an electronic sense, all of the above still holds true if I'm not mistaken. chris adams

The key class is something I considered but discarded for this reason: When implementing an actual hotel lock system the key is a physical object and not represented in software. Instead it sends data into the program as input, like a user typing on a keyboard. Instead, I would make a class called keyReader which has some method that catches the event of a card being swiped and then invokes the proper methods using the data from the card. Nate Weimer


the key will also have an insert service. Which may be enough to make it a class.
Jesse Shieh

Aah, I see your point, Christopher. Okay, then for a REAL, SPECIFIC implementation, what are ALL the classes you'd create – both concrete and abstract? That's what this question is asking. Mark Guzdial
Anybody know how a real hotel door with a card key works? It's actually quite fascinating. No database is involved at all. Each lock knows a sequence of random, big, prime numbers, arranged in a circular buffer. When you push the key in, the door compares the number on the card to the "current" number. If it matches, the door opens. If it doesn't match, check the next number in the sequence. If it matches, then that number becomes the "current," the old one no longer works, and the door opens. Mark Guzdial

Jesse, why would the key have an insert service? Is it the responsibility of the key to be inserted? Mark Guzdial
Good point, Nate. As long as one understands that the KeyReader is an object, not the verb of reading. Mark Guzdial

I have an interesting comment to make. I was talking to a friend last spring about PGP and encryption. One of the things we discussed was the existance of a system that would encrypt your hard drive when logged off and would require a special ring to decrypt. The ring contained circutry that would respond to the contact on the computer. The ring acted as the key. The interesting part was that the key was issued a challenge by the computer. The key then returns a correct response to the challenge. The challenge is encrypted, so the only key that actually works is the key that has the private key for decrypting challenges.

I think this constitutes an example of a "key" that contains data and performs a function. In this example, it may not be necessary, but it provides for good abstraction for "special" cases. A key class can be benificial.
Christopher Henke



Link to this Page