# OOP Design

OOP Design is a good exercise on how to split up our system into different components. It's like React Components before they were cool but instead of React Components, we separate our system into different objects/classes. The main difficulty with problems like these are that they are opened ended and force you to think abstractly and creatively. One of the other main goals of this exercise is to be able to draw out diagrams to help with communicating abstract ideas before they are implemented in code. These problems are language agnostic.

## Design an ATM

Using object oriented programming principles, class diagrams and activity diagrams, design an ATM. We are being explicit here, however, you might not get this luxury from an interviewer as they might just ask, "Using object oriented design, design an ATM".

## Requirements and Goals of an ATM

- Takes in a card and authenticates user
- User has the option to deposit, withdraw and view balance

## Strategy Guide

### Talk Through User Stories

To start off, ask yourself the question, "What can an ATM do?"

Appropriate user stories would include:

- *An authentication user story*: User inserts their card into the ATM and they are prompted to enter their PIN. If the PIN is correct, open up a menu. If the PIN is incorrect, the user gets prompted to input it again. After a certain amount of times, you get booted off the system.

- *A deposit user story*: After authentication is done, the user wants to deposit some cash. They will click the "deposit" button (on the screen or using some button), input the amount of cash they are depositing, input PIN, insert cash into cash dispenser, click a confirmation, print receipt, update the amount in their account (in the background), ask if they want to do another transaction.

- *A withdraw user story*: After authentication is done, the user wants to withdraw some cash. They will click the "withdraw" button (on the screen or using some button), input the amount of cash they want to withdraw, input PIN, take cash from the cash dispenser, print receipt, update the amount (in the background), ask if they want to do another transaction.

- *A balance inquiry user story*: After authentication is done, the user wants to see a summary of their balance. They will click the "balance inquiry" button (on the screen or using some button), they are brought to some screen with a total balance shown on it, ask if they want to do another transaction.

*Minimum Solution*: Ideally 2 of them would be good

### Draw Activity Diagrams

The next step is turn that chat about the user stories into activity diagrams or flow charts. It's not enough to just talk about it, we need to document it for our theoretical team.

#### Authentication Activity Diagram


#### Balance Inquiry Activity Diagram


#### Deposit Activity Diagram


#### Withdraw Activity Diagram


### List/Talk About the Main Components of an ATM

After you are done with the activity diagrams, it's time to think about the main components of an ATM. This usually means the possible physical parts. Sometimes developers skip over this in interviews and just go straight for something like an account class, which is a viable class but we want to illustrate something more. The reason we do this is to demonstrate the idea that OOP is predicated on mapping some "real world object" to a classes and subclasses.

*Full Solution*:

- ATM
- Card reader
- Keypad
- Screen
- Cash dispenser
- Deposit slot
- Receipt slot
- Network infrastructure (for authentication, updating balance, etc.)

*Minimum Solution*: The minimum amount of components to identify are the cash dispenser, the screen, and ATM. Sometimes, candidates might do one slot for all the functionality.

### Class Diagram of an ATM System

By this point, the board should be filled with a lot of references for the candidate to be able to discuss, list, and draw relationships among the main classes of an ATM system.

*Note*: If the candidate gets "network infrastructure" above, ask them how they would split up those functionalities among classes. Example: How much functionality should the ATM have itself? Or does the bank do all of it and just sends the results back to the ATM. Like authentication: Does the ATM just depend on the bank to do it? Or does the ATM have that functionality built in locally so that it doesn't need to go over the network to do it?

*Note*: Encourage them to actually think about what properties and methods should exist in each class. This can take a very long time so feel free, in the interest of time, to bring them back and have them start drawing out the diagram.

*Full Solution*:

- ATM: Can have an ATMID to distinguish it from other ATMs as well as a location as properties
- Keypad: Where we enter PIN or amounts
- Screen: Different screens and messages shown; could be a touch screen ATM
- Printer: Print receipts
- CashDispenser: The ATM component that dispenses cash
- DepositSlot: The ATM component that accepts cash
- Bank: Which bank owns the ATM/holds customer account info
- CardReader: The ATM component that reads the magnetic strip
- Account: User account information
- Checking extends Account
- Savings extends Account
- Customer: General user information
- Card: The actual card
- Transaction: What type of transaction it can be
- Deposit extends Transaction
- Withdraw extends Transaction


*Minimum Solution*:

- Account
- ATM
- Screen
- Slot
- Deposit
- Withdraw


*Note 1*: A conversation point here is the transaction class. We can have this as a "main class" and deposit and withdraw can "extend" it. This can actually be extended (ha) to the account class. It can be the main class and savings and checking account can extend it.

## Additional Discussion Points

Nearing the end of the problem, we can choose to discuss how might we want to add additional features to our ATM:

- What if we wanted to add a transfer money option?
- What if we wanted to add credit card accounts or investment accounts?
- What if we wanted to deposit checks as well?
- What if we added a "status" functionality to our transactions?
- Success, Failure
- What if we added a "status" functionality to our customers?
- Active, Closed

### Actors of an ATM System

Another great talking point to get them thinking about the entire system is to talk about the "actors" of a system. ATMs are physical entities that have limitations. It can't fit unlimited money and doesn't generate its own money if it runs out. So, there are actors in many systems that we don't traditionally think about.

#### Operator

- Turn ATM ON/OFF
- Refill ATM with cash, receipts, ink
- Take out deposited checks and cash

#### Customer

- See Main functionality

#### Bank Admin

- Generate reports based on operator