To understand and apply the SOLID principles in the context of a financial management system, let’s

break down the task systematically, adhering to the principles.

1. Single Responsibility Principle (SRP)

Definition:
Every class should have one and only one reason to change. This principle ensures that a class has a
single responsibility or functionality.

Violation of SRP:

Consider a FinancialReport class that generates, saves, and emails financial reports:

class FinancialReport:

def generate_report(self, data):

# Generate the report

print("Report generated.")

def save_to_file(self, filename):

# Save the report to a file

print(f"Report saved to {filename}.")

def email_report(self, recipient):

# Email the report

print(f"Report emailed to {recipient}.")

Adhering to SRP:

Break the responsibilities into separate classes:

class ReportGenerator:

def generate_report(self, data):

print("Report generated.")

class ReportSaver:

def save_to_file(self, filename):

print(f"Report saved to {filename}.")

def email_report(self, recipient):

print(f"Report emailed to {recipient}.")

Now, each class has a single responsibility.

2. Open-Closed Principle (OCP)

Definition:
Classes should be open for extension but closed for modification. This encourages extending
functionality via inheritance or composition rather than altering the class itself.

Violation of OCP:

A TaxCalculator class that directly handles multiple tax types:

class TaxCalculator:

def calculate(self, income, tax_type):

if tax_type == "GST":

return income * 0.1

elif tax_type == "IncomeTax":

return income * 0.2

else:

raise ValueError("Unsupported tax type")

Adhering to OCP:

Use polymorphism to extend the functionality:

class TaxCalculator:

def calculate(self, income):

pass

class GSTCalculator(TaxCalculator):

def calculate(self, income):

return income * 0.1

def calculate(self, income):

return income * 0.2

Now, adding a new tax type requires only a new class, not modifying the existing ones.

3. Liskov Substitution Principle (LSP)

Definition:
Derived classes must be substitutable for their base classes without affecting the functionality of the
program.

Violation of LSP:

Consider a Shape hierarchy:

class Shape:

def area(self):

pass

class Rectangle(Shape):

def __init__(self, width, height):

self.width = width

self.height = height

def area(self):

return self.width * self.height

class Square(Rectangle):

def __init__(self, side):

super().__init__(side, side)

Here, Square inherits from Rectangle but overrides its behavior inconsistently, violating LSP.

Adhering to LSP:

Refactor to separate Square and Rectangle:

class Shape:
 def area(self):

pass

class Rectangle(Shape):

def __init__(self, width, height):

self.width = width

self.height = height

def area(self):

return self.width * self.height

class Square(Shape):

def __init__(self, side):

self.side = side

def area(self):

return self.side * self.side

Now, both classes independently adhere to their behavior.

4. Interface Segregation Principle (ISP)

Definition:
A class should not be forced to implement methods it does not use. Instead, use smaller, specific
interfaces.

Violation of ISP:

A single FinancialOperations interface:

class FinancialOperations:

def calculate_interest(self):

pass

def process_transaction(self):

pass
 def generate_statement(self):

pass

A LoanAccount implementing this interface unnecessarily implements methods it doesn’t need.

Adhering to ISP:

Split the interface into smaller, more specific ones:

class InterestCalculator:

def calculate_interest(self):

pass

class TransactionProcessor:

def process_transaction(self):

pass

class StatementGenerator:

def generate_statement(self):

pass

Now, LoanAccount can implement only the InterestCalculator interface.

5. Dependency Inversion Principle (DIP)

Definition:
High-level modules should not depend on low-level modules. Both should depend on abstractions.

Violation of DIP:

A ReportPrinter depends directly on a PDFReport class:

class PDFReport:

def print(self):

print("Printing PDF report.")

class ReportPrinter:
 def print_report(self):

pdf = PDFReport()

pdf.print()

Adhering to DIP:

Introduce an abstraction:

class Report:

def print(self):

pass

class PDFReport(Report):

def print(self):

print("Printing PDF report.")

class ExcelReport(Report):

def print(self):

print("Printing Excel report.")

class ReportPrinter:

def __init__(self, report: Report):

self.report = report

def print_report(self):

self.report.print()

Now, ReportPrinter depends on the Report abstraction, not a specific implementation.

Conclusion

By applying SOLID principles, the financial management system is modular, maintainable, and
extensible. Each principle ensures clear separation of concerns, flexible designs, and adherence to
best practices in object-oriented programming.