10 Replies - 579 Views - Last Post: 12 June 2014 - 05:27 AM Rate Topic: -----

#1 saikrishnan7  Icon User is offline

  • New D.I.C Head

Reputation: 0
  • View blog
  • Posts: 7
  • Joined: 10-June 14

Banking - Application Design

Posted 10 June 2014 - 01:01 PM

Hello all,

I am planning to create a banking application. The idea of the post is to get some feedback on the classes that I have come up with to translate the below mentioned requirements into a working application. Please review and let me know if I can proceed to the next step of writing actual code for the classes that I have come up with.

Here are the requirements:

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.

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.

The following are the classes I have come up with to reflect the requirements.

Bank
private Map<accountNumber, Customer> customers
public createCustomer(String firstName, String lastName, Date DOB, initialAmount, String accountType), public findCustomer(String accountNumber)

Customer
private String firstName(get,set), private String lastName(get,set), private Date DOB(get,set), private List<Account> accounts

abstract Account
String accountNumber(get,set), double balance, double minimumBalance
void deposit(double amount), void withdraw(double amount), void checkBalance()

CheckingAccount extends Account
No additional fields/methods.

SavingsAccount extends Account
private double interestRate
private calculateInterestRate()

Is This A Good Question/Topic? 0
  • +

Replies To: Banking - Application Design

#2 modi123_1  Icon User is online

  • Suitor #2
  • member icon



Reputation: 9207
  • View blog
  • Posts: 34,589
  • Joined: 12-June 08

Re: Banking - Application Design

Posted 10 June 2014 - 01:07 PM

Quote

The idea of the post is to get some feedback on the classes that I have come up with

The classes seem to be lacking depth. Not a whole lot of actual variables, or functions.

To ask you back, do the classes outline appear to cover your entire usecase? Is there something you feel is not being represented well?
Was This Post Helpful? 0
  • +
  • -

#3 baavgai  Icon User is online

  • Dreaming Coder
  • member icon

Reputation: 5832
  • View blog
  • Posts: 12,685
  • Joined: 16-October 07

Re: Banking - Application Design

Posted 11 June 2014 - 02:51 AM

In Customer, what exactly is the point of private getters and setters? Why have setters at all? You CheckingAccount has nothing do add? That's a big red flag. what does checkBalance do? Again, on Account, why would you ever have a setter for the number? Along those lines, I unique customer id would be helpful. Does accountNumber need to be a string?

When designing a class structure, begin with the public. Indeed, all things private are implementation details. Imagine the work flow. If you have something like "customer can open or close a checking account" you should be thinking about a method and which object should implement it. It looks like an account can have a closed status, so that would have been the first thing I described.
Was This Post Helpful? 0
  • +
  • -

#4 saikrishnan7  Icon User is offline

  • New D.I.C Head

Reputation: 0
  • View blog
  • Posts: 7
  • Joined: 10-June 14

Re: Banking - Application Design

Posted 11 June 2014 - 04:48 AM

View Postmodi123_1, on 10 June 2014 - 01:07 PM, said:

The classes seem to be lacking depth. Not a whole lot of actual variables, or functions.


Thanks a lot for your valuable feedback. Yes, I had this feeling too. One of the problems I can't seem to find a solution for, is the interaction between the objects.To elaborate on this, I have visualized the following: My bank class is pretty much going to be the interface for the end user. Say, I display a list of numbered choices like this, 1.Deposit 2.Withdraw 3.Close Account. I am planning to have a method GetUserChoice() to get these displayed. Then when the user selects an option, for eg. deposit, I get the account number and the amount to be deposited and call the appropriate account object's deposit method with the amount to be deposited. Now my question is whether I need to think through this interaction during design and come up with methods in the bank class that reflect these interactions or is it just an implementation thing? In other words, should I have methods in the bank class corresponding to all the questions/choices I would have to present at the terminal? eg. GetDepositDetails() asks for the account number and the amount and then calls deposit() in Account after validation - should I mention the GetDepositDetails() as part of my design?

View Postmodi123_1, on 10 June 2014 - 01:07 PM, said:

To ask you back, do the classes outline appear to cover your entire usecase? Is there something you feel is not being represented well?

After reviewing my classes, I clearly felt the Customer class should have atleast 3 methods:

void addAccount(Account account), void deleteAcccount(Account account), List getAccounts()

since there is no means of adding a new account or deleting an existing account from an existing customer without these methods if the user chooses to do so.

Also the Bank class must have an openAccount() and closeAccount() to maintain its Customers.
Was This Post Helpful? 0
  • +
  • -

#5 saikrishnan7  Icon User is offline

  • New D.I.C Head

Reputation: 0
  • View blog
  • Posts: 7
  • Joined: 10-June 14

Re: Banking - Application Design

Posted 11 June 2014 - 05:07 AM

View Postbaavgai, on 11 June 2014 - 02:51 AM, said:

In Customer, what exactly is the point of private getters and setters? Why have setters at all?

I don't mean to have them as private. The way I have presented it seems to be ambiguous. I actually meant to say that it will be a private field with getters and setters in default scope accesible by the bank class in case Customer Names have to be changed/set(in case of a new customer).

View Postbaavgai, on 11 June 2014 - 02:51 AM, said:

You CheckingAccount has nothing do add? That's a big red flag. what does checkBalance do?

Thanks a lot. I was not aware of that. I can't seem to come up with fields or methods relevant only to CheckingAccount. What is to be done in cases like these? Just abandon inheritance?

Sorry, checkBalance should be returning a double. It checks for the balance available in the current acount object.

View Postbaavgai, on 11 June 2014 - 02:51 AM, said:

Again, on Account, why would you ever have a setter for the number? Along those lines, I unique customer id would be helpful. Does accountNumber need to be a string?


Yes, I realise that there shouldn't be a setter for Account Number. Could you please elaborate on how exactly would having a CustomerID be helpful? I thought of having it initially an mapping every account number to a CustomerID. But I just felt I was doing it for the sake of having a CustomerID and maybe not really using it.
Since Account numbers are a long sequence if numbers, I thought it would be better to have them as string. Is this a bad choice?

View Postbaavgai, on 11 June 2014 - 02:51 AM, said:

When designing a class structure, begin with the public. Indeed, all things private are implementation details. Imagine the work flow. If you have something like "customer can open or close a checking account" you should be thinking about a method and which object should implement it. It looks like an account can have a closed status, so that would have been the first thing I described.

Thanks for the suggestion. I will adopt this approach going forward. Regarding the account having a closed status, I was initially thinking of having a field to represent the account status but decided against it. I am planning to delete an account from the system if it is closed. Is this wrong?
Was This Post Helpful? 0
  • +
  • -

#6 saikrishnan7  Icon User is offline

  • New D.I.C Head

Reputation: 0
  • View blog
  • Posts: 7
  • Joined: 10-June 14

Re: Banking - Application Design

Posted 11 June 2014 - 05:17 AM

My reply was getting long winded, so I thought I should post my modified classes and methods in a new post.

Bank
Attributes - private Map<accountNumber, Customer> customers
Metods - public createCustomer(String firstName, String lastName, Date DOB, initialAmount, String accountType), public findCustomer(String accountNumber), public openAccount(), public closeAccount()

Customer
Attributes - private String firstName, private String lastName, private Date DOB, private List<Account> accounts
Methods - addAccount(Account account), deleteAcccount(Account account), List getAccounts(). Getters, Setters for Name,DOB.

Account
Attributes - String accountNumber, double balance, double minimumBalance
Methods - void deposit(double amount), void withdraw(double amount), double checkBalance()

Checking
Same as account

Savings
Attributes - private double interestRate
Metods - private calculateInterestRate()
Was This Post Helpful? 0
  • +
  • -

#7 astonecipher  Icon User is offline

  • Major DIC Head
  • member icon

Reputation: 673
  • View blog
  • Posts: 2,970
  • Joined: 03-December 12

Re: Banking - Application Design

Posted 11 June 2014 - 05:54 AM

I would personally have a Boolean return type for closeAccount().

If for some reason the account could not be closed, negative balance for instance, you return false
Was This Post Helpful? 0
  • +
  • -

#8 baavgai  Icon User is online

  • Dreaming Coder
  • member icon

Reputation: 5832
  • View blog
  • Posts: 12,685
  • Joined: 16-October 07

Re: Banking - Application Design

Posted 11 June 2014 - 06:58 AM

View Postsaikrishnan7, on 11 June 2014 - 08:07 AM, said:

Sorry, checkBalance should be returning a double.


Understood. This could also be getBalance, which would clarify the intent.


View Postsaikrishnan7, on 11 June 2014 - 08:07 AM, said:

Account numbers are a long sequence if numbers, I thought it would be better to have them as string.


If you can't use a single number, then a string is a reasonable choice. I was thinking you'd want your Bank to assign the number, so it needn't be particularly long.


View Postsaikrishnan7, on 11 June 2014 - 08:07 AM, said:

I am planning to delete an account from the system if it is closed. Is this wrong?


You have as a criteria "An account once closed can never be reopened." Now, if you're using a sequentially assigned number from Bank, this is pretty trivial. However, if you're using some "long sequence" then you're going to have to remember what it is, so you don't use it again. As a practical design consideration, it's nice to have a closing balance.

Ok, why a customer id? If nothing else, it makes overloading your Equals simple. It could make Bank easier to use.

Consider:
class Bank:
    public Customer createCustomer(...)
    public Customer findById(int custId)
    public Customer findForAcctNum(String acctNum)
    public boolean removeCustomer(int custId)
    public boolean addAccount(int custId, Account acct)



You're right, you don't need it. However, you'd have a unique identifier for a customer in the real world. You'd also have a data store backend with a primary key.
Was This Post Helpful? 0
  • +
  • -

#9 saikrishnan7  Icon User is offline

  • New D.I.C Head

Reputation: 0
  • View blog
  • Posts: 7
  • Joined: 10-June 14

Re: Banking - Application Design

Posted 11 June 2014 - 08:43 AM

Thank you, baavgai. I know at some point I will need to override equals method for Customer and Account, but I am just not able to visualise at the moment how or why I will have the need to compare 2 accounts or customers. Could you kindly give me a scenario and help me understand? With my current design, I think it is very difficult or even impossible to compare 2 customers correctly.
Was This Post Helpful? 0
  • +
  • -

#10 saikrishnan7  Icon User is offline

  • New D.I.C Head

Reputation: 0
  • View blog
  • Posts: 7
  • Joined: 10-June 14

Re: Banking - Application Design

Posted 11 June 2014 - 08:50 AM

Also, does the class which will interact with the user, the Bank class, have all the action methods (like deposit, withdraw, getBalance, openAccount etc.) that are present in other classes and then call those methods? Or, is it OK to just have a run() method in the bank class which will get all user input and directly call methods like deposit, withdraw in other classes? If I follow the first approach, it feels like there need not be any methods at all in the bank class, but in the 2nd, it feels like the bank class should have all the methods that are in other classes too. I am getting very confused with this. Please help me understand.
Was This Post Helpful? 0
  • +
  • -

#11 baavgai  Icon User is online

  • Dreaming Coder
  • member icon

Reputation: 5832
  • View blog
  • Posts: 12,685
  • Joined: 16-October 07

Re: Banking - Application Design

Posted 12 June 2014 - 05:27 AM

View Postsaikrishnan7, on 11 June 2014 - 11:50 AM, said:

does the class ... have all the action methods ... that are present in other classes and then call those methods? ...


This can be tricky, honestly. You want to avoid duplication of code. However, you also want to avoid having to walk down an object chain every time you want to get things done. There is no solid rule on this, I'm afraid.

Think about what a class is. It's first, and foremost, a container for data. It's methods are those that act on the data it contains. You Bank class will hold customers. Its funtions are those that manipulate customers. Your customer holds customer info and accounts and the methods which manipulates that data.

Let's go back to the beginning. Since I seem to be at risk of confusing you, I'll offer up a quick sketch of how I'd start.

class Bank:
    addCustomer(name: string): Customer
    getCustomerByName(name: string: List<Customer>
    getCustomerById(id: int): Customer
    removeCustomer(id: int): boolean
    getCustomers(): List<Customer>

class Customer:
    getId(): int 
    getName(): string
    getAccounts(): List<Account>
    getAccount(acctNum: int): Account
    addCheckingAccount(opening: float): Account
    addSavingsAccount(opening: float): Account
    closeAccount(acctNum: int): boolean 

class Account:
    isClosed(): boolean
    close(): void
    getAcctNum(): int
    getBalance(): float
    getAcctType(): [ Savings, Checking ]
    deposit(amount: float): void
    withdraw(amount: float): void



Note there there is NO user interface here. This is just a model for playing with data.
Was This Post Helpful? 0
  • +
  • -

Page 1 of 1