Scribd
Upload
6 views6 pages

Sathvik Oop

The document outlines the application of SOLID principles in a financial management system, detailing each principle with definitions, violations, and adherence examples. It emphasizes the importance of single responsibility, open-closed, Liskov substitution, interface segregation, and dependency inversion principles for creating modular and maintainable code. The conclusion highlights that following these principles leads to a more flexible and well-structured system.

Uploaded by

syedafrose890
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
6 views6 pages

Sathvik Oop

The document outlines the application of SOLID principles in a financial management system, detailing each principle with definitions, violations, and adherence examples. It emphasizes the importance of single responsibility, open-closed, Liskov substitution, interface segregation, and dependency inversion principles for creating modular and maintainable code. The conclusion highlights that following these principles leads to a more flexible and well-structured system.

Uploaded by

syedafrose890
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 6

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}.")


class ReportEmailer:

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


class IncomeTaxCalculator(TaxCalculator):

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.

You might also like