Guided Exercise: Advanced Method Overriding - Customizing Account Services #101
akash-coded
started this conversation in
Tasks
Replies: 1 comment
-
|
Task 1 - Sayan Dey class Account { } Task 2 - Sayan Dey public class SavingsAccount extends Account { } Task 3 - Sayan Dey public class SalaryAccount extends Account { } Task 4 - Sayan Dey public class CurrentAccount extends Account { } |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Guided Exercise: Advanced Method Overriding - Customizing Account Services
Objective: To understand and implement method overriding in depth, providing specialized behaviors in subclasses for a common operation, and observe polymorphic behavior.
Scenario:
JPMC has decided to implement a system for applying monthly account service charges. However, these charges are not uniform. They vary based on the type of account:
Accounts (if any were to be created directly, though less common) might have a very basic or no charge.SavingsAccounts might be charged if their balance falls below certain thresholds relative to their minimum balance.SalaryAccounts, being premium, will have this charge waived.CurrentAccounts will have a fixed charge due to the nature of services they offer.This requires each account type to handle the "apply service charge" operation in its own unique way, a perfect use case for method overriding.
Prerequisites:
BankingSystemDemo.javafile from the previous exercise.Instructions:
You will modify the existing classes within your
BankingSystemDemo.javafile.Task 1: Introduce a Generic Service Charge Method in the
AccountClassBankingSystemDemo.javafile.Accountclass.applyMonthlyServiceCharge(), is defined in the baseAccountclass. It provides a default behavior.SavingsAccount,SalaryAccount,CurrentAccount) will override this method to implement their specific service charge rules.Task 2: Override Service Charge Logic in
SavingsAccountNavigate to the
SavingsAccountclass.Override the
applyMonthlyServiceCharge()method.balanceis less thanminimumBalance + 500(or another threshold you define, e.g.,minimumBalance * 1.2), a service charge of ₹50.00 should be debited. Otherwise, the charge is waived.@Overrideannotation.balanceonly if the charge is applied and successful. You can use the existingdebit()method, but be careful: thedebit()method inSavingsAccountitself has minimum balance checks. For a service charge, you might want to bypass this specificminimumBalancecheck (i.e., a service charge can take you belowminimumBalance, or up to it). For simplicity here, let's assume the service charge can reduce the balance, even if it slightly dips below the usual operationalminimumBalancebut not below zero. Or, more robustly, define a small, fixed charge that is applied if conditions are met and directly deduct it.Explanation:
@Override: This annotation tells the compiler that this method is intended to override a method from a superclass. If the signature doesn't match a superclass method (e.g., due to a typo), the compiler will flag an error.SavingsAccount. It checks its own conditions (balancevs.minimumBalance) to decide on the charge.balance: Note thatbalancewasprotectedinAccount, soSavingsAccountcan access it directly. If it wereprivate,SavingsAccountwould need to usegetBalance()and a newprotected void setBalance(double newBalance)or rely onsuper.debit()if applicable. For service charges, direct manipulation (if rules are simple) or a dedicatedprotected adjustBalance()method can be cleaner than using the standarddebitwhich has its own operational rules.Task 3: Override Service Charge Logic in
SalaryAccountNavigate to the
SalaryAccountclass.Override the
applyMonthlyServiceCharge()method.SalaryAccounts as a benefit.Explanation:
SalaryAccountcompletely redefines the behavior. It doesn't apply any charge. This is a common use of overriding – to provide a "do nothing" or "do something entirely different" implementation.Task 4: Override Service Charge Logic in
CurrentAccountNavigate to the
CurrentAccountclass.Override the
applyMonthlyServiceCharge()method.Explanation:
CurrentAccountalso provides its unique logic – a fixed charge.SavingsAccount,SalaryAccount,CurrentAccount) explicitly callsuper.applyMonthlyServiceCharge(). This is because their charging logic is entirely self-contained and doesn't need to build upon the base class's (empty/generic) behavior for this particular method. If the base class did something essential that needed to happen first, then asupercall would be appropriate.Task 5: Demonstrate in
BankingSystemDemo.java(main method)Navigate to the
mainmethod in yourBankingSystemDemoclass.At the end of each customer's simulation block (Tasks 5.1, 5.2, 5.3), add a call to
applyMonthlyServiceCharge()for their respective account.For example, for Customer 1 (Priya Sharma - Savings Account):
Do similarly for
rohanSalaryandinnovateBiz.Observe Polymorphism in the "End of Day Branch Summary" (Task 5.4):
Modify the loop that iterates through
allAccountsto also callapplyMonthlyServiceCharge(). This is where polymorphism shines!Task 6: Compile and Run
BankingSystemDemo.javafile.SavingsAccount.SalaryAccount.CurrentAccount.acc.applyMonthlyServiceCharge()invokes the correct method for each account type, even thoughaccis declared asAccount.Explanation of Key Concepts Illustrated:
applyMonthlyServiceCharge()in each subclass.@OverrideAnnotation: This helps prevent subtle bugs by ensuring your overridden method signature correctly matches the superclass method. If you misspelledapplyMonthlyServiceChargeor changed its parameters in a subclass without@Override, you'd be creating a new method, not overriding, and the polymorphic calls wouldn't work as expected.When you have code like:
myAccountrefers to (e.g.,SavingsAccount,SalaryAccount) and calls that specific object's version ofapplyMonthlyServiceCharge(). This is dynamic method dispatch. It's powerful because you can write generic code that operates on base class types (Account), and it automatically adapts to the specific behaviors of subclasses.Imagine if you didn't use overriding. You might have one large
applyMonthlyServiceCharge()method in theAccountclass with manyif (account instanceof SavingsAccount) { ... } else if (account instanceof SalaryAccount) { ... }checks. This becomes very hard to manage as you add new account types. With overriding, each account type encapsulates its own charging logic. If JPMC introduces a "StudentAccount" later, you just create that class, extendAccount, and overrideapplyMonthlyServiceCharge()with its specific rules, without touching the existing, tested code for other account types (Open/Closed Principle).Beta Was this translation helpful? Give feedback.
All reactions