From having worked on Prog. Assg. #2, you should be quite familiar with the hypothetical keypad lock device on which it was based. Part of that assignment was to develop the Java class KeyPadLock1, which implements the KeyPadLock interface.
Your task in this lab is to take your instructor's version of that class (accessible via the first link in the previous sentence) and to modify it so that it uses a queue —rather than the digitsEntered[] array— to store the digits most recently entered on the keypad. Specifically, you are to use an instance of the class QueueViaArray, which implements the interface Queue.
Call the resulting class KeyPadLock1Q.
One of the bad decisions made by several students in Prog. Assg. #2 was to allow a state of affairs in which the digitsEntered[] array contained "old" data that had become irrelevant. Consider, for example, a lock having a secret code of length four. If the user presses the keys 1, 2, 3, 4, 5, and 6, in that order, the fact that 1 and 2 were pressed has become irrelevant, due to the fact that those two key presses are not among the most recent four. For the locking device to "remember" those two key presses is unnecessary and thus wasteful of resources.
This observation leads to the following requirement: Your queue should never have irrelevant data stored in it.
For the purpose of testing your work, provided is the Java application KPL1Q_Tester and the supporting class KeyPadLockTester. Notice that the latter class's processCommands() method can be used to test an instance of any class that implements the KeyPadLock interface. This illustrates the power of polymorphism, which in this case allows a variable declared to be of type KeyPadLock to store a reference to an object of any class that implements the interface of that name.
|
| Corresonding output |
|---|
Creating a new KeyPadLock1Q object ... Enter secret code: 57823 A keypad lock with code 57823 has been created. Enter one or more commands: 1345oc Performing command 1; afterwards, lock is CLOSED Performing command 3; afterwards, lock is CLOSED Performing command 4; afterwards, lock is CLOSED Performing command 5; afterwards, lock is CLOSED Performing command o; afterwards, lock is CLOSED Performing command c; afterwards, lock is CLOSED Enter one or more commands: 78o Performing command 7; afterwards, lock is CLOSED Performing command 8; afterwards, lock is CLOSED Performing command o; afterwards, lock is CLOSED Enter one or more commands: 23o Performing command 2; afterwards, lock is CLOSED Performing command 3; afterwards, lock is CLOSED Performing command o; afterwards, lock is OPEN Enter one or more commands: 57823cocoq Performing command 5; afterwards, lock is OPEN Performing command 7; afterwards, lock is OPEN Performing command 8; afterwards, lock is OPEN Performing command 2; afterwards, lock is OPEN Performing command 3; afterwards, lock is OPEN Performing command c; afterwards, lock is CLOSED Performing command o; afterwards, lock is OPEN Performing command c; afterwards, lock is CLOSED Performing command o; afterwards, lock is CLOSED Performing command q; afterwards, lock is CLOSED Goodbye. |
If, when executing this application, you provide a command-line argument (or what jGrasp calls a "run argument"1), it will be interpreted as the name of the file from which input is to be read. Otherwise, the application will read input from the keyboard. The figure to the left shows sample input and that to the right shows the corresonding output produced by the KPL1Q_Tester application, assuming that the KeyPadLock1Q class that it is using is correct.
You are to submit your work in the usual way. That would be to submit the file KeyPadLock1Q.java to the CMPS 144L lab8_dir folder. As usual, your comments should include the names of your team members, a list of the names of any other people who assisted you, and an account of any behavioral defects of your class.