@abhimanyusirohi Hi!

In the example, we have two classes that represent account types in a bank. In the first version of this code, a relationship was created between a conventional bank account called CommonBankAccount and a specific bank account called PayrollBankAccount. Both have features of a common bank account: cashOut (withdraw), deposit, check the account balance. However, some CommonBankAccount methods don’t make sense for PayrollBankAccount, for example, income(). Payment bank accounts have no income. That is, this inheritance relationship shouldn’t exist in the first place. They are different classes as you said.

LSP ensures this kind of thing doesn’t happen: inheritance should not be used if classes that only have something in common. The best way to handle with this context is by using Composition instead. I created a class to function as a bank account manager, named AccountManager, and it has all the behaviors that an account can have. The two classes that once had a relationship, no longer have a relationship: they are correctly isolated. Both use the manager to implement their behavior and only import behaviors that they use. This avoids code repetition and allows an account’s functionality to evolve without breaking the implementations that use it.