3

I am designing a Bank Application which deals with Customers having FD Accounts.

There are two approaches to this :

Approach 1

In this the customer has a list of accounts. The bank application will manage the accounts through the customers.

My mentor feels this is the correct approach. :-P

class Customer
{
     String name;
     Date   dob;
     .
     .

     Account[] accounts = new Account[5];
}

class Account
{
     int   accNo;
     float amount;
     .
     .
}

Approach 2

In this approach each account has its associated customer reference stored. The Bank application will now manage the accounts and customers independently.

I feel this is the correct approach. :-)

class Customer
{
     String name;
     Date   dob;
     .
     .         
}

class Account
{
     Customer customer;
     int   accNo;
     float amount;
     .
     .
}

Now my issues are :

  1. Ideally the bank application should worry more about the account than the customer. For example, the bank should have methods like addAccount() : which will add account and create a customer implicitly if it is the first account of the customer and deleteAccount() : which will delete the account and delete the customer implicitly if it is the last account.
  2. There can be a use case in the future where an account can have multiple customers. So that can be accommodated easily in the second approach than the first.

Considering all this, please can you say which is a better Object Oriented Approach here?

Also how is this actually implemented in a real Bank?

  • With approach 2, how does a teller get the accounts for a customer when they ask for their balances? With approach 1, how do you get the owners for an account so as to mail account statements? Customers-accounts is an m-to-n relationship and should go both ways, not just one. Also, joint accounts is as easily handled in approach 1 as multiple accounts for a customer is in approach 2. – outis Aug 13 '15 at 8:05
  • so does than mean both Customer and Account must have references to each other ? – monicaG Aug 13 '15 at 13:01
  • The correct way to model this is the way which makes the code simplest for the expected use cases. In this case, your manager is probably right, although I can see benefit in a hybrid approach too. – Maybe_Factor Jan 19 '17 at 1:49
0
  1. Ideally the bank application should worry more about the account than the customer. For example, the bank should have methods like addAccount() : which will add account and create a customer implicitly if it is the first account of the customer and deleteAccount() : which will delete the account and delete the customer implicitly if it is the last account.

What is your definition of 'worry'? :)

As mentioned in @James Anderson's answer, the activities of customers and accounts are monitored, so it will not be customary if accounts' records are physically wiped out from your persistence storage (e.g. databases, or possibly simply flat files if this is actually just a small academic assignment borrowing a bank's context) the moment deleteAccount() is performed.

What you can probably do here is to introduce temporal fields that can mark the start and end timestamps of the record, whether the record is logically considered inactive, or both (i.e. four fields). The final option may make sense if you want to track customers/accounts that are temporarily suspended, with the option that they can be activated later. E.g. a simplified example on a timescale:

01/01 ------------ 04/30 -------------- 08/31 -------------- 12/31
* Account created  * Account            * Account            * Account
  and active         suspended            active               inactive
  1. There can be a use case in the future where an account can have multiple customers. So that can be accommodated easily in the second approach than the first.

True... to some extent. I only hope the following line is only meant to signify the intent to use a multi-element data structure, not a hard limit of 5 accounts:

 Account[] accounts = new Account[5];

An alternative approach is to simply store references in both domain classes, e.g. in Java:

public class Customer {
    // ...
    Set<Account> accounts = new HashSet<>();
}

public class Account {
    // ...
    Set<Customer> customers = new HashSet<>();
}

In this way, you can easily identify all the accounts of a single Customer, or all the associated Customers of an Account. To refine this even further, maybe these relationships can be stored as Map<Account, AccountType> and Map<Customer, CustomerType> associations too.

7

Oh Dear.

Your design is how bank applications were designed in the 1970s. Myself and several thousand professionals have spent decades undoing this design error to get systems looking more like option 1.

Banks deal with customers the account is just a mechanism for dealing with some of the customers money.

More importantly the stack of regulators who weigh down on any financial business are very interested in customers. They want to know about all the assets and liabilities of any individual or business; not the state of an single account. Failing to report all the accounts held by an individual, or, having more than one customer record for the same person, could get you fined or eventually lead to the loss of your banking licence.

As will deleting the customers data when an account is closed! You need to retain everything for several years.

  • ok, thank you for shedding light on how it works in real world. :) but what if a customer does not have a account ? will his data still be saved in the bank n be just marked inactive ? – monicaG Aug 13 '15 at 13:04
  • @monicaG -- yep you must keep records of all closed accounts, and, the customer records associated with it. It is even quite common to keep records of customers that were turned down :-) – James Anderson Aug 14 '15 at 15:28
3

This seems like a classical Has Many/Belongs To relationship type. What we usually do is kind of a merge between your 2 options, where:

  1. A Customer has a list of the many Accounts he has.
  2. An Account has a reference to the Customer it belongs to.

That being said, @James Anderson is accurate as he states the importance of customers rather than the account itself.

-3

Object Oriented Modeling, its used to represent the real world in a Software Application.

In other times, a single account, had only, and only one customer, assigned. These days, several customers, can be assigned and removed from an account.

There are many ways to model an application, so there is not really a "100% bad" or "100% good" way.

Your example is a "many-to-many" associations.

And, usually an additional, intermediate class is added.

One way to start, is model each data set, or object, explicitly excluding relations to each other, and add those relations, later.

class CustomerClass
{
     int   CustNo;
     String name;
     Date   dob;
     .
     .         
} // class CustomerClass

class AccountClass
{
     int   accNo;
     float amount;
     .
     .
} // class AccountClass

class AccountCustomerClass
{ 
     int   acccustNo;

  // How to relate both, added later
} // class AccountClass

Later, pick one of the "edge" classes ("Account" or "Customer"), that better suits your needs, and add a "relationship" class collection or array.

In this example, let's take "Customer":

class AccountClass
{
     int   accNo;
     decimal amount;
     .
     .
} // class AccountClass

class AccountCustomerClass
{ 
     int   accustNo;
     DateTime RegistrationDate;
     .
     .
     AccountClass Account;
} // class AccountClass

class CustomerClass
{
     int   CustNo;
     String name;
     Date   dob;
     .
     .
     AccountCustomerClass Accounts[];
} // class CustomerClass

Note, that using "AccountCustomerClass Accounts[]", in "AccountClass", instead of "CustomerClass" is not "bad", is just an alternative way.

  • 2
    As written, AccountCustomerClass doesn't add anything. "many-to-many" in OOP is generally modeled by adding a field to each class holding a collection of weak references to the other class. A join class arises in the relational model, but it refers to each joined element, rather than being referred to by one of the elements. Floating point isn't suitable for monetary values. Appending Class to all class names is redundant. – outis Aug 13 '15 at 20:09
-3

Here's a tip that will teach you to fish.

"model the world as it really is in software"

Look yourself in the mirror and say the two design options as a sentence.

Option 1: 'I am a customer and I have many accounts.'

Option 2: 'I am an account and I have a customer.'

Which one sounds silly? which one sounds real? Pick the one that works in the real world. Stick to the ubiquitous language - read Domain Driven Design (Eric Evans).

Rinse & repeat through the rest of your very successful career!

protected by gnat Jan 18 '17 at 16:08

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.