|
Steps in Object Oriented design [ Case Study Global Commerce Bank ] |
|
|
Written by Veena Devi
|
Steps in Object Oriented design [ Case Study Global Commerce Bank ]
Case Study of Global Commerce Bank
There are three types of bank employees who deal with Loans in the bank
Loan Advisors: Advises customers on various loans and can also initiate loans. The final approval of loans can be done only by the Bank Manager.
Bank Manager: Primarily responsible for approving all loans and fixing of special interest rates for Business Loans. The bank manager can also initiate loans
Teller: Can accept EMIs.
Step 1: Identify all the ‘nouns’ (type of objects or classes) in the requirement (Loan part has been done already)
– Loan Advisor
– Bank Manager
– Teller
Step 2: Identify the commonalities between classes (Generalization) if it is obvious.
– Do not force fit generalization where it doesn’t make sense
– Common factor is that all of them are employees of bank
– Employees have some common attributes
Step 3: In any given situation, start with the simplest object which can be abstracted into an individual class
– In the classes identified above, Employee is the simplest class
Step 4a: Identify all the member variables and methods the class should have
– Class Employee
• Member Variables: EmployeeID, Email
• Methods: Get/Set Employee ID, Get/Set Email
Step 4b: Let us go ahead and identify the member variables and methods for the rest of the classes
– Class LoanAdvisor
• Member Variables: EmployeeID, Email
• Methods: Get/Set EmployeeID, Get/Set Email, InitiateLoan
– Class BankManager
• Member Variables: EmployeeID, Email
• Methods: Get/Set EmployeeID, Get/Set Email, InitiateLoan, ApproveLoan
– Class Teller
• Member Variables: EmployeeID, Email
• Methods: Get/Set EmployeeID, Get/Set Email, AcceptEMI
Step 5: Ensure that the class is fully independent of other classes and contains all the attributes and methods necessary
Step 6: Keep All data members private or protected
Step 7 and 8: The methods in class should completely abstract the functionality. The methods in the class should not be a force fit of procedural code into a class
Step 9: Inherit and extend classes from the base class ONLY IF situation has scope for it.
– Shift the commonalities among classes to the base class
Step 10: Define the “Has-A” and “Uses-A” relationship among classes
– (Is-A has been defined already in previous step)
– Uses-A and Has-A could’ve been defined if we had considered the entire case study
Step 11: Keep the number of classes in your application under check
(Do not create any unnecessary classes)
– (Design in previous slide doesn’t have any unnecessary classes)
Step 12: Always REVIEW your design
– To eliminate any redundancy
– To assess whether the relationships identified make sense
|
Java Articles 
