Test Driven SOLID Principles

Learn the single responsibility principle, which says a class should have only one reason to change. Avoid god classes by splitting code into small, focused classes and modules.

Apply the single responsibility principle by refactoring a bloated banking service into dedicated print, loan, and notification services, improving maintainability through modular design.

Refactor to apply the single responsibility principle by moving balance management to the account class, delegating add and withdraw money to account, and using a notification service for alerts.

Apply the open–closed principle by keeping existing code closed for modification and open for extension, using a vehicle base class with car, bike, and future truck subclasses.

Drive the open and closed principle by updating the notification service to send an otp with personalized greetings and a disclaimer, guided by tests.

Explore applying the open-closed principle by refactoring a notification service to support email and SMS without modifying existing code, using abstract methods and inheritance to pass tests.

learn about the Liskov substitution principle, which requires that derived classes be substitutable for base classes without altering program behavior, illustrated by a rectangle and square inheritance example.

Apply the Liskov substitution principle to banking accounts, ensuring fixed deposit behavior remains substitutable for the general account without breaking tests.

Apply Liskov substitution principle by introducing a withdrawal service and saving account, refactoring the banking service to support withdraw money, align tests, and clarify responsibilities.

Explore the interface segregation principle of SOLID, which splits large interfaces into small, client-specific ones so classes implement only the methods they need, illustrated with a conversion interface example.

Implement a Google Pay UPI payment using an initial UPI payments interface, applying the interface segregation principle to improve design, with tests guiding pay money, scratch card, and cashback behaviors.

Apply the interface segregation principle to split a large payments interface into separate interfaces for scratch cards and cashback, enabling in-house payments, Paytm, and Google Pay while updating tests.

Explain the dependency inversion principle, where high level modules depend on abstractions rather than concrete classes, enabling decoupled design via interfaces implemented by low level components like keyboard and monitor.

Apply dependency injection to design a bank atm service that withdraws money from an atm using a debit card (and supports credit card) with test-driven validation.

Applies dependency inversion by introducing a bank card interface, injecting debit and credit card implementations into the bank ATM service, and handling transaction charges.