The Atm.hpp File

 <  Free Open Study  >  

 // Atm.hpp: This is the header file for the main classes, which  // reside solely on the ATM side of the application. #ifndef _ATM_ #define _ATM_ // Files that deal with transactions will often define an ATM_SIDE // or BANK_SIDE macro to describe which application space they are // in. The transaction code gets compiled into each application, // but some methods are only appropriate for one address space or // the other. #include <iostream.h> #include <stdlib.h> #include ''consts.hpp'' // Forward references class Transaction; class TransactionList; class Network; // These two pointers provide the path for the Card // Reader's directory, which simulates where a card is // inserted, and the ATM's directory, where eaten cards // are placed. Normally these would be hardware addresses, // but for our simulation they are going to be directories // in a file system. A person copies a BankCard file // into the CardSlots directory to simulate inserting // a card into the ATM and the ATM removes the file to // simulate ejecting the card. The ATM moves the file to its // internal directory to simulate eating a card. The Bank // Card file is a one-line ASCII file that consists of seven // numeric characters representing the account number and // a four-digit PIN number. The bank card itself is the // same name as the physical card reader's ''name'' data member. // These two directory strings are assigned in the main driver // function to the first two command line arguments passed // in. extern char CardSlots[]; extern char ATMSlots[]; // The following two constant strings are used for // portability in simulating ejecting and eating cards. extern const char* file_delete_format; extern const char* file_move_format; // The relationship between the PhysicalCardReader // and the CardReader is that the CardReader is a // wrapper class for the PhysicalCardReader. The // latter is very reusable in that it reads only raw // data off of a card. The CardReader is specific to // the domain of ATM and therefore is not reusable. It is // responsible for distributing the system intelligence // from the ATM to its pieces (in this case, the CardReader). class PhysicalCardReader {      char name[small_string]; public:    PhysicalCardReader(char* n);      int readinfo(char* buf);      void eject_card();      void eat_card(); }; // The following classes model the physical pieces of the ATM // class. They include CardReader, Display, Keypad, DepositSlot, // CashDispenser, and ReceiptPrinter. Of particular interest is // the SuperKeypad. This class exists solely due to an analysis of // the behavior of the system. This analysis indicated much // cohesion between the Keypad and DisplayScreen. Cohesion is one // metric for determining when two or more classes need // encapsulation inside of a containing class. It is useful to note // that a pure data driven analysis methodology would be unable to // detect such classes since they are motivated by behavior and do // not exist in the real-world model. class CardReader {      PhysicalCardReader cardReader;    int validcard;      char account[small_string];      char pin[small_string]; public:      CardReader(char* n);      int read_card();      int get_account(char*);      int get_pin(char*);      void eject_card();      void eat_card(); }; class Keypad {       int enabled; public:      Keypad();      void enable();      void disable();      char getkey(); }; class DisplayScreen { public:      void display_msg(const char*); }; class SuperKeypad{      Keypad *keypad;      DisplayScreen *display; public:      SuperKeypad();      ~SuperKeypad();      void display_msg(const char*);      int verify_pin(const char* pin_to_verify);      Transaction* get_transaction(char* account, char* pin); }; class CashDispenser{       int cash_on_hand; public:      CashDispenser(int initial_cash);      int enough_cash(int amount);      int dispense(int amount); }; class DepositSlot{ public:      int retrieve_envelope(); }; class ReceiptPrinter{ public:      void print(TransactionList* translist); }; // The BankProxy class is the representative of the Bank class in // the ATM's address space. It is a wrapper class for the Network, // which is itself a wrapper for the exact byte-transfer mechanism // (pipes, in this example). class BankProxy {    Network* network; public:    BankProxy(Network* n);    int process(Transaction*); }; class ATM {       BankProxy* bank;       CardReader* cardReader;       SuperKeypad* superKeypad;       CashDispenser* CashDispenser;       DepositSlot* depositSlot;       ReceiptPrinter* receiptPrinter;       TransactionList* translist; public:      ATM(BankProxy* b, char* name, int cash);      ~ATM();      void activate();      int retrieve_envelope();      int enough_cash(double amount);      int dispense_cash(double amount); }; #endif 
 <  Free Open Study  >  


Object-Oriented Design Heuristics
Object-Oriented Design Heuristics (paperback)
ISBN: 0321774965
EAN: 2147483647
Year: 1996
Pages: 180

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net