OO design - Banking

[Prasanna Raman]

I'd like to create a banking application for which I've written down the specifications. Please review and comment. If this looks OK, I will start working on the classes.

A bank can have any number of customers, and each customer can have multiple checking and/or savings accounts.

Checking: The customer can open or close a checking account. He can deposit or withdraw money. The account balance cannot be negative. If a customer tries to withdraw more than he has in his account, the transaction will be declined

Savings: The customer can open or close a savings account. The minimum balance in the account should be $100. This account accrues interest at 5% compounded daily.

Opening an account: The customer will need to provide some personal details, and have a minimum balance of $100 to open either account.

Closing an account: The customer can close his account at any time. The money has he has in the account at that point will be returned to him. An account once closed can never be reopened.

[Jeanne Boyarsky]

While a real bank is clearly more complicated, that is a good subset. Think about how you would uniquely identify an account and a customer.

[Prasanna Raman]

Thanks, Jeanne

I am thinking of having an accountID field to uniquely identify an account and an SSN field for uniquely identifying a customer, but I am confused as to why I have to think about these at this point. Could you please help me understand?

[Jeanne Boyarsky]

How to uniquely identify an object (also called a key) is an important part of it. Tacking that on later is often harder than designing it upright. It also affects method names. findCustomer() takes what parameters?

Account id is fine for the accounts. Consider using something else for the customer id. (Like a made up customer id.) Social security number is sensitive information so you don't want to pass it around unnecessarily.

[Prasanna Raman]

OK, thank you! Can I start thinking about my classes now and write them down?

[Jeanne Boyarsky]

Prasanna Raman wrote:OK, thank you! Can I start thinking about my classes now and write them down?

Go for it!

[Prasanna Raman]

I've written down the classes with attributes and methods. I've added the types for attributes but haven't thought about the method signatures yet. Please take a look and comment.

Bank

Map<CustomerID, Customer> customers
getCustomerDetails(), addCustomer(), findCustomer(), deleteCustomer(), openAccount(), closeAccount()

Customer

String firstName, String lastName, String phoneNumber, Date DOB, String customerID
generateCustomerID()

abstract Account

String accountID, AccountType accountType, AccountStatus accountStatus, double balance
open(), close(), deposit(), withdraw(), getBalance()

CheckingAccount extends Account

open(), close(), deposit(), withdraw()

SavingsAccount extends Account

double interestEarned
open(), close(), deposit(), withdraw(), calculateInterest()

enum AccountType

CHECKING, SAVINGS

enum AccountStatus

ACTIVE, CLOSED

[Jeanne Boyarsky]

What about updating the customer? For example, what if a customer gets married and changes her name?

[Prasanna Raman]

Thank you, Jeanne. I've added the editCustomer() method to the customer class.

Bank

Map<CustomerID, Customer> customers
getCustomerDetails(), addCustomer(), findCustomer(), editCustomer(), deleteCustomer(), openAccount(), closeAccount()

Anything else that I'm missing?

[Junilu Lacar]

Rather than speculating about attributes and methods each of your classes needs, I suggest you approach system design from a user's point of view first. A user doesn't care about the kind of objects/classes that are used to model a system. A user cares about *functionality* and getting something done. So start with a few use cases or user stories: How would a user of your banking system interact with the system and what is the goal of each interaction? You could spend hours speculating about different attributes and methods of your classes but if you don't think about usage scenarios, you may still not have a system that delivers value to a user.

I suggest you think about these interactions first, then decide on the *candidate classes* that might be involved in these interactions:

1. A customer wants to open an account with the bank
2. A customer wants to make a deposit
3. A customer wants to make a withdrawal

Assume that the "actor" who interacts directly with the system is a Branch Teller.

Just start with these simple scenarios first, then when you have implemented them, you can add more functionality to the system by thinking of additional usage scenarios (maybe have the Customer interact directly with an ATM).

[Junilu Lacar]

Just thinking about these scenarios I mentioned, I can already eliminate Bank as a candidate class. Sure, it's a banking system but that doesn't mean there needs to be a Bank class.

[Michael Gomez]

Prasanna Raman wrote:Thanks, Jeanne

I am thinking of having an accountID field to uniquely identify an account and an SSN field for uniquely identifying a customer, but I am confused as to why I have to think about these at this point. Could you please help me understand?

Using a SSN to uniquely identify a customer is a bad idea, think about the following:

*Privacy Issue - in your sample application it might not matter, but in a real application you wouldn't want to expose those details, better to follow good standards.
*Not a true PK - Although rare, its possible a Social Security number can change, usually as a result of identity theft, etc.

Better to use a auto-incrementing surrogate key.

Ref:
http://databases.about.com/od/specificproducts/a/primarykey.htm

Social Security Numbers do not make good primary keys for a table of people for many reasons. First, most people consider their SSN private and don’t want it used in databases in the first place. Second, some people don’t have SSNs – especially those who have never set foot in the United States! Third, SSNs may be reused after an individual’s death. Finally, an individual may have more than one SSN over a lifetime – the Social Security Administration will issue a new number in cases of fraud or identity theft.

[Junilu Lacar]

This is why I recommend starting with some simple usage scenarios first. Discussions about things like primary keys and ids are way too premature at this point where you don't even have any working code or a high-level conceptual map of the system. It's like designing a vehicle by first agonizing over the size of the nuts and bolts you're going to use to build it. Sure these details are going to be important considerations at some point but I hardly think they're the appropriate ones to start thinking about when you're just starting to design the system, even a very simple one.

[Prasanna Raman]

Thank you for your valuable suggestions, Junilu. What I had in mind was to get a complete picture of all the objects and how they interact with each other even before I started writing any code. I thought writing code would then be straightforward if I had the complete picture in mind; I wanted to decide how I'd store my attributes, write down my method signatures etc. before starting to write code. I will have your suggestions in mind as I keep working through this.

[Prasanna Raman]

Jeanne Boyarsky wrote:What about updating the customer? For example, what if a customer gets married and changes her name?

Sorry, Jeanne. I think I didn't think this through properly when I said in my earlier post that I'd just have an editCustomer() method in the Bank class.

I think I've missed out the getter and setter methods for firstName, lastName, phoneNumber and DOB in my Customer class. Now, I am a bit confused as to how the customer would make the request to get his name or phone number changed. Should the bank class also have edit methods for all the attributes with each of those methods calling the corresponding setter method in the Customer class? I am not able to think of doing this any other way but I somehow don't feel that I've got it right.

[Junilu Lacar]

That approach is called "Big Up Front Design" which has been proven time and time again to be an unrealistic way to design a system. You can't think of everything up front and no matter how much time you spend carefully thinking about it, when it gets down to coding, something always changes because the vast majority of people just can't think in that much detail. This is coming from many years of experience of many, many people. Iterative and incremental design and coding is a better way to go. We are authors, just like the people who write literary stories or musicians who compose music. We have to go through many iterations before we can get things right. The idea that you can think of everything up front and then have a straightforward translation to code just does not align (or very, very *rarely does if ever) with the reality of the way the human brain and the cognitive process works.

[Joel Christophel]

Prasanna Raman wrote:Sorry, Jeanne. I think I didn't think this through properly when I said in my earlier post that I'd just have an editCustomer() method in the Bank class.

I think I've missed out the getter and setter methods for firstName, lastName, phoneNumber and DOB in my Customer class.

I think you're right. You don't need any methods in the Bank class concerning setting the properties of Customers. Just use getters and setters in your Customer class.

Prasanna Raman wrote:I am a bit confused as to how the customer would make the request to get his name or phone number changed.

This depends on how you actually implement the API you're creating. But no matter how you do it, once a Customer logs in, he should be able to change some of the properties of his Customer object. Certain properties would require an administrator to change. For example, Bank of America requires that you bring in an ID to prove a name change.

So this still only requires setters in the Customer class, but access to certain properties would be limited.

[Junilu Lacar]

Sigh.

Ok, I'm going to make one more attempt to pull you guys out of the depths of implementation thinking and up to a more appropriate (and IMO, realistic) level of thinking -- the place I would start if I were to go through a design exercise with my team.

So, you want to create a simple banking system, huh? Answer these questions first: (please, just humor me)

1. Who would be the primary user of this program? A bank teller? An actual customer?
2. How would this primary user access the system? Via a terminal connected to the bank's intranet? Over the web, via the bank's public website?
3. What's a common task that this primary user would perform with this program?
4. What's another common task that this primary user would perform with this program?

If you haven't thought about these things yet, how can you start thinking about classes, attributes, and methods? Isn't that just a lot of premature speculation?

Like I said before, it's like you're trying to build a car by starting out with the detailed specifications of the nuts and bolts. Why would you think about nuts and bolts without first thinking about the features your car will have and how they will benefit those riding in it?

[Prasanna Raman]

Junilu Lacar wrote:Sigh.

Ok, I'm going to make one more attempt to pull you guys out of the depths of implementation thinking and up to a more appropriate (and IMO, realistic) level of thinking -- the place I would start if I were to go through a design exercise with my team.

Thank you again Junilu! Sorry, I am not trying to ignore your advice and continue in my own way but I'm seriously confused at this point. If my understanding is right, some of the other advice that I previously got in this forum have been to design it the way I started here. So, I think this is all going over my head a little now

Junilu Lacar wrote:1. Who would be the primary user of this program? A bank teller? An actual customer?

An actual customer

Junilu Lacar wrote:2. How would this primary user access the system? Via a terminal connected to the bank's intranet? Over the web, via the bank's public website?

Via a terminal

Junilu Lacar wrote:3. What's a common task that this primary user would perform with this program?

Opening an account

Junilu Lacar wrote:4. What's another common task that this primary user would perform with this program?

Withdraw/deposit money

Junilu Lacar wrote:If you haven't thought about these things yet, how can you start thinking about classes, attributes, and methods?

To be fair to myself, I think I did think through these things before I started. I think I documented at least some of these in the requirements I wrote down initially. But where I went away from what you're suggesting is that I didn't start coding these first. I am only a beginner to OOP, so I thought I'd be better off trying to think through the design first and then code.

[Junilu Lacar]

The advice you received previously was probably given in the context of a specific problem. Now the context is much larger and there are too many specifics -- trying to account for all of them will just overwhelm you. So it's best to take one small problem at a time but keep the big picture in mind to guide you.

Given your answers, one might think this is what you have in mind:

Scenario: Creating a new account

A customer comes into the bank branch office, goes up to a terminal where this program is running. The customer selects the option to create a new account. The program prompts the customer to enter information that is needed to create a new account, the program creates a new account and displays a message to that effect to the user.

Does this sound like a reasonable story to you? In my experience as a bank customer, it doesn't quite go like that.

Let me give you my version of the story and tell me what you think.

Scenario: Creating a new account

A customer comes into the bank branch office, goes up to a teller, and requests to open a new account. The teller leads the customer to a banking officer who takes over from there (the teller goes back to the bank counter). The banking officer exchanges pleasantries with the customer and establishes that the customer wants to open a personal checking account. The bank officer logs in to his/her terminal and fires up the retail banking application. The application has a menu of things that can be done with retail accounts. The bank officer selects the "Create new checking account" option from a menu. The bank officer goes through the new account entry process, gathering information from the customer and entering it into the program. The bank officer also verifies and records the customer's personal identification information (Name, address, telephone numbers, SSN, driver's license #, etc.). The bank officer then asks the customer to sign a signature card that will be kept on file to verify signatures on checks that will be made against the account. The bank officer asks the customer for the amount of the initial deposit, informing the customer of the minimum amount required to open a new account. After confirming all the information that was entered to create the new account, the banker takes the initial deposit amount from the customer and completes the "Create new checking account" process. The banker then gives the customer a newly-printed confirmation sheet with information about the new account that was just created.

That's quite a lot more than what those few questions and answers before might suggest, isn't it? Well, that's pretty much what happens in the real world of software development. You get an initial problem statement, ask a few questions, get a few answers, then you think you might know enough. Then you think about the problem some more, ask some more questions and get more information that makes you realize there's more to the whole thing than you thought before. This "discovery process" happens over and over again all throughout development and while my version of the story is pretty close to what actually happens in the real world, there are probably more things I have left out.

Your job as a designer is not to try to think of everything that you could possibly need to include in the program and rack your brain trying to think of what you could have possibly left out. Rather, your job is to try to distill the story that you know right now in such a way that you can start with an initial design, something simple but representative of your current "model" of the system, that you can code and test. This is what's called a "slice" or initial cut. Once you have written some tests and code that works for that one small slice, then you'll have a better idea of what kind of adjustments you'll need to make (refactoring) so that your initial design can weather new additions or changes (it's flexible) to accommodate the next "slice" (increment) of the bigger story. Do this a number of times (iterations) and you'll eventually have a program that enables its user to do something of real value.

Think about this a little bit, discuss, and then we can move on to the next step in the making of your first slice/cut of this "banking" pie.

[Prasanna Raman]

Thank you, Junilu. I agree with your version of the banking process, but what I was hoping to build here was just a simulation of it. I may add a GUI or develop a Web page for this later on but right now, I just want to simulate one or two functionalities that happen in a real bank on my computer terminal.

The main functionalities that I wanted to implement are opening an account, closing an account, making a deposit and withdrawing money. Finally, the customer should also be able to change his details like his last name or phone number. Even for this small subset of functionalities, is trying to think of the whole design wrong? If so, how and where would I start here?

[Junilu Lacar]

Prasanna Raman wrote:Thank you, Junilu. I agree with your version of the banking process, but what was hoping to build here was just a simulation of it. I may add a GUI or develop a Web page for this later on but right now, I just want to simulate one or two functionalities that happen in a real bank on my computer terminal.

That's exactly the approach you should be taking. My point is that you can't just dive down into details without having an overall "vision" of how things will fit together first. Even with a simplified simulation, you should still keep the big picture in mind and not stray too far away from it.

The main functionalities that I wanted to implement are opening an account, closing an account, make a deposit and withdraw money. Finally, the customer should also be able to change his details like his last name or phone number. Even for this small subset of functionalities, is trying to think of the whole design wrong? If so, how and where would I start here?

"Wrong" would not be the right word to use. Trying to think of all the *details* would be less productive / less effective. Thinking about the *high-level* concepts first and getting a rough overall picture in place is a better way to start.

So far you have:
1. Customer can open an account
2. Customer can close their account
3. Customer can make a deposit
4. Customer can make a withdrawal

This a great starting point. Next, I would distill the story I related about opening an account into a few important/key steps. You don't have to put all the details all at once. Recognizing what things can be deferred as "detail" work and what things are key to the "framework" of the program is what makes design challenging. So take my account of what happens when a customer opens an account and boil it down to what you think are the important parts of the story that will provide a simple framework that you can start working with.

[Prasanna Raman]

Thank you, Junilu.

Opening an account: The customer goes to the bank and says that he wants to open a new account. The teller asks him what type of account he'd like to open - checking or savings? The customer says what he needs and then the teller tells him the minimum amount if there is any, to open the account with and asks him to fill out a form - in this case, a form that asks him for his first name, last name, phone number and DOB. Then, the teller enters the information, saves it in the system thereby opening a new account for the customer.

Deposit/ Withdraw: An existing customer can deposit or withdraw money from his account. He is asked for his credentials and then prompted with these options. He picks deposit/withdraw and then enters an amount. The transaction then happens and his balance is adjusted accordingly.

Closing an account: An existing customer may want to close his account. In this case, the money he has in his account is returned to him and his account is marked "Closed".

[Junilu Lacar]

Awesome!

Now break it down to a little more detail -- this is where we start to think *a little bit* about implementation but we still want to stay away from thinking too deeply about classes. Starting with the goal of "opening an account", what parts of a the program will be involved? Hint: start with "responsibilities" if you can't name actual parts. E.g. there needs to be a part of the program that is responsible for displaying prompts, menus, and input fields. This is the user interface. What other responsibilities can you think of? To help you out, try to fill in and expand the following:

User interface - displays prompts, menus, and input fields
(something) - (does something)
(something) - (does something)
... and so on

If this were a face-to-face discussion, we'd be drawing this out on a whiteboard and it would take us about 30 minutes of discussion and drawing to come up with a usable "context diagram" but since this discussion is asynchronous, this will take a while. But bear with me; this will be good, I promise.

[Prasanna Raman]

Junilu Lacar wrote:But bear with me; this will be good, I promise.

Thank you Sure, I am really excited. I know I'm going to struggle through this and might be asking a lot of dumb questions so please bear with me!

User interface - displays prompts, menus, and input fields.
Collecting user details - collects all the details the user has entered through the interface.
Processing - does some action based on what the user needs. For example, creating the account and assigning it to the customer.
Saving - saving the customer details.

[Junilu Lacar]

Prasanna Raman wrote:

Junilu Lacar wrote:But bear with me; this will be good, I promise.

Thank you Sure, I am really excited. I know I'm going to struggle through this and might be asking a lot of dumb questions so please bear with me!

User interface - displays prompts, menus, and input fields.
Collecting user details - collects all the details the user has entered through the interface.
Processing - does some action based on what the user needs. For example, creating the account and assigning it to the customer.
Saving - saving the customer details.

Good ideas but a little bit off track. We're going for Noun - Responsibility. You have given Verb - Responsibility. But that's Ok. Sometimes it's not so easy to pin down the right Noun to use.

Let's refine this one at a time, starting with "Collecting User Details - collects all the details the user has entered"

One way to "test" whether or not you have a good candidate Noun and Responsibility is to ask "Why?" a few times (it's actually recommend to ask "Why?" five times to get to the real reason). Here we go:

1st time: Why do you need something that collects the user's details?

[ibrahim yener]

I have already done such program in Java.
If i find it in my backup files i post it.

[Tim Cooke]

ibrahim yener wrote:I have already done such program in Java.
If i find it in my backup files i post it.

Can I recommend that you don't please.

The value that the OP is getting out of this discussion thread is the discovery of his own system requirements and the thought process that goes into putting together a design. Posting a ready made solution is not going to help with that, in fact it will probably just confuse things significantly.

[Junilu Lacar]

Thanks for the offer Ibrahim but I think Prasanna will benefit more by working through this and writing his/her own solution. Please don't post any of your own code -- especially not *all* of it, otherwise I'll have to do some "moderating" -- until he/she has had a chance to write his/her own.

(@Prasanna: sorry but I'm unsure of your gender)

[ibrahim yener]

I got it !!!

[Prasanna Raman]

ibrahim yener wrote:If i find it in my backup files i post it.

Thank you for offering to help, Ibrahim but as Tim and Junilu have already said, I think I'll get a lot more out of this discussion than any code can help.

Junili Lacar wrote:@Prasanna: sorry but I'm unsure of your gender

It's he :)

[Prasanna Raman]

Junilu Lacar wrote:1st time: Why do you need something that collects the user's details?

I think I got confused a little bit here. I think I started thinking "methods". One method to prompt questions to the user, followed by one that processes the information and then a method that saves the information.

[Junilu Lacar]

Prassana wrote:It's he

Thanks. I tried to google around a bit but could not find a definitive answer. It seems like it's like the western name "Leslie" -- it's used by both genders.

Prassana wrote:I think I started thinking "methods". One method to prompt questions to the user, followed by one that processes the information and then a method that saves the information.

Ah... but again you get ahead of yourself. That's OK, programmers are tinkerers by nature and the urge to get down to the nuts and bolts is strong. You must learn to control that urge and give in to it at the appropriate time.

Step back again and think of *nouns* -- things that will be responsible for performing a task or series of tasks. Each of these things should be focused on a single responsibility.

So this "thing" that collects the user information entered in the UI, how would it work with other "things" to accomplish the end goal, which is to have a brand new customer account with some money in it? Why is this thing and its responsibility an important part of achieving the end goal? (That was the 2nd "Why?")

[Prasanna Raman]

Junilu Lacar wrote:Ah... but again you get ahead of yourself.

Sorry, I'm trying hard not to but have still ended up falling for it Will try harder

I've tried this again.

User interface - displays prompts, menus, and input fields.
Customer - enters his personal information when prompted by the user interface.
Banker - receives the details from the customer, creates an account for him.

[Junilu Lacar]

Now you stepped a little too far back. We got some statements of functionality from the Customer's point of view already. Now we need to get some descriptions of functionality at the Application level -- but in a general sense.

UI is part of the application.

What other part of the application would be involved in creating a new account? Some kind of repository of information maybe, so that data that was entered can be persisted and used at a later time?

Between the UI and this "repository of data", what other part(s) of the application might we need to get the job of creating a new account done? Hint: we are starting to think about application layers.

[Prasanna Raman]

Junilu Lacar wrote:Between the UI and this "repository of data", what other part(s) of the application might we need to get the job of creating a new account done? Hint: we are starting to think about application layers.

Sorry, I am really racking my brain but don't seem to come up with anything In layman's terms, between the UI and the "repository of data" I'd think there needs to be some processing done to do the actual work of verifying the information and creating the account but I'm not sure if this is what you wanted

[Junilu Lacar]

Prasanna Raman wrote:Sorry, I am really racking my brain but don't seem to come up with anything In layman's terms, between the UI and the "repository of data" I'd think there needs to be some processing done to do the actual work of verifying the information and creating the account but I'm not sure if this is what you wanted

Don't be sorry, you're on the right track! There absolutely needs to be something in between the UI and the data repository that takes care of the "business" of creating an account. UI and data repository are "infrastructure" services. They deal with actual physical things like terminals and disk drives or memory. The thing in between deals with concepts or "entities" like Accounts, Customers -- the concepts that make up your problem domain. In other words, these are your Domain Objects. There's another category of things that can get involved too: Business Services.

Now we're really getting into the different application layers. Even though you are starting off with a small chunk, it's still good to have an idea of the general organization of the layers because it helps you assign responsibilities properly.

Grok this first and discuss anything that still confuses you. Then we'll move on.

[Prasanna Raman]

Thank you! So, there's UI first, then some "business logic" done to the inputs we have from the UI which involves the various objects like the Customer, Account etc., and then there's the "respository of data" which is where this needs to be stored. Do I need to understand something else at this point?

What is business services?

[Junilu Lacar]

Let me answer by way of examples. Something that "knows" what needs to be done to create a new account might be called an AccountCreationService. Something that knows about making a deposit might be called a DepositService. And so on. These services encapsulate "rules" for how things happen. They don't necessarily do things directly but they are the central "hub" through which things gets done. Most enterprise applications employ the concept of Business Service and there a many different ways and technologies that you can use to implement them in Java. Of course you don't have to go beyond anything more than POJOs (Plain Old Java Objects) for this exercise. Creating a full-blown enterprise app is way beyond the scope and practicality of a discussion like this.

[Prasanna Raman]

Thank you! What should I do next?