Implementation of Software Design Patterns illustrated through Banking and Financial System examples
Table of contents
- Factory Method Design Pattern
- Abstract Factory Method Design Pattern
- Singleton Method Design Pattern
- Prototype Method Design Pattern
- Builder Method Design Pattern
- Chain Of Responsibility Method Design Pattern
- Command Method Design Pattern
- Observer Method Design Pattern
- Strategy Method Design Pattern
Defines an interface for creating objects, letting each factory decide which specific type of object to create.
My Example: Creates different types of bank accounts through the same interface
Main idea: Factory Method → One abstract creator (AccountFactory), multiple concrete factories, one product type (Account). The abstract factory (AccountFactory) defines the create_account() factory method — but doesn’t decide which account to create. Each concrete factory (CurrentAccountFactory, SavingAccountFactory) implements create_account() differently so that the client code calls the same interface, but gets different results. Check out the example code here →
Defines an interface for creating set of related objects, letting each bank factory decide which specific product to create.
My Example: Creates different types of banking products -Accounts, Cards and loans through the same interface
Main idea: Abstract Factory Method → One abstract factory (BankFactory), multiple concrete factories(InvestmentBankFactory, CommercialBankFactory, RetailBankFactory), multiple product types (Account, Card, Loan). The abstract factory (BankFactory) defines creation method for each product type (create_account(), create_card() create_loan()), but doesn’t decide which exactly account, card, or loan to create. Each concrete factory implements these methods to produce a cohesive family of products appropriate for that bank, so client code calls the same interface but gets different results depending on the factory used.
Check out the example code here →
Ensures that only one instance of a class exists, and provides a global point of access to it.
My Examples:
- Database Connection: Ensures that all modules (payments, loans, users) share a single database connection instead of creating a new one every time.
- Transaction Logger: Maintains one unified logging system so all records are stored in a single file, console, or monitoring system rather than in multiple independent logs.
- Session Manager: Guarantees that each user has only one active session, preventing multiple logins or duplicated user data in memory.
Main idea: The creation of the instance is fully controlled by the class itself. For example, in a Session Manager, only one global instance of the session handler exists — if a user is already logged in, a new login attempt will not create another session.
Check out the example code here →
Go to -> Creational Design Patterns
Acts as a bridge to connect incompatible interfaces or formats
My Example: Integration of incompatible payment APIs (like PayPal and Stripe) under a unified interface process_payment() for the banking system.
Main idea: Helps integrate different payment APIs using a unified interface process_payment() as a technical method that executes the actual payment, while the client interacts with the system through the high-level transfer_money() method of banking application. Check out the example code here →
Provides a simple unified interface to a set of complex subsystems
My Example: Money Transfer in a Banking System
Main idea: Instead of dealing with complex subsystems or components, the client only needs to call a single transfer_money() method, implemented as a Facade. The client doesn’t need to know all the individual methods, the underlying resources, or the correct sequence of calls. Check out the example code here →