Visitor Design Pattern Cont..
Here in displayDetails method we can see many if else conditions and if we have more classes for different - different Account then these if else conditions will grow vertically. Each time we add some functionalities for these accounts classes, each time we need to write these many conditions and type checking logic which is not good.
So one solution can be suggested here is move this displayDetails method in Account class as abstract method without any argument, and let all derived classes implement/override this method.
Then we can simply call displyDetails method for each account as following
Account account = new CurrentAccount();
account = LoanAccount();
So far so good! But in this approach the problem is, if we need to display some other details or let say we want to display different Account opening Forms for different Account type. Then we will be either adding displayForm(Account account) method with if else conditions or we will be ending up adding one more method in the Account classes.
Adding methods in Account classes is not good and not advised, as Account class is just for representing data/information and should be used as datatype only. There should not be any business logic in any Account class.
Solution: This problem can be solved easily by applying Visitor pattern.
- Visitor pattern helps us in removing all if else conditions for hierarchy checking (from DisplayHandler class).
- Visitor pattern helps us in keeping business logic separate from hierarchy classes (from Account classes).
- Visitor patterns helps us adding more functionality without changing hierarchy classes (Account classes).
Step1. Create an interface as following
Step2. Create a visitor implementation for display account details as following
Step3. Create an interface as following
Step4. Let all account classes implement this interface. or we can avoid step3 by adding an abstract method accept and let all account classes implement it. its up tu you what you want to choose.Lets update the Account classes.
Step4. Update DisplayHandler class as following
Your implementation is complete now, you can see there are no if else conditions or type checking.
How to test: To test the functionality we can have our main class as following
Account type: Current
Account Balance: 500
Withdrawal Limit: 10000
Account type: Saving
Account Balance: 1000
Account type: Loan
Account Balance: 100000
Loan Amount: 100000
Now suppose we want to add some more functionality to display different Account opening Forms as discussed above before Solution. to achieve this we need to add a displayForms(Account account) method in DisplayHandler class, no need to add if else conditions just do as following.
After creating above class now create a DisplayFormVisitorImpl.java class similar to DisplayAccountVisitorImpl.java by implementing visitor interface and add display forms logic in each of overloaded methods.
This way we can avoid adding if else conditions and modifying Account classes each time a new functionality is added.