class SmsSender(MessageSender): # Another low-level def send(self, message: str) -> None: # Twilio logic here pass
class Sparrow(FlyingBird): def move(self): return self.fly(100) def fly(self, altitude: int): return f"Flying at altitude"
class DiscountCalculator: def calculate(self, amount: float, strategy: DiscountStrategy) -> float: return strategy.apply(amount) Subtypes must be substitutable for their base types. Deep Dive Issue: Python's duck typing hides LSP violations. A subclass might accept different argument types or raise unexpected exceptions.
def generate_pdf_report(self): print(f"PDF: self.name") # Presentation Python 3- Deep Dive -Part 4 - OOP-
from abc import ABC, abstractmethod class MessageSender(ABC): # Abstraction @abstractmethod def send(self, message: str) -> None: pass
class MultiFunctionDevice(ABC): @abstractmethod def print(self, doc): pass @abstractmethod def scan(self, doc): pass @abstractmethod def fax(self, doc): pass class SimplePrinter(MultiFunctionDevice): def print(self, doc): ... def scan(self, doc): raise NotImplementedError # Forced dependency def fax(self, doc): raise NotImplementedError
class Employee: def __init__(self, name, salary): self.name = name self.salary = salary def calculate_pay(self): return self.salary * 0.8 # Business rule def generate_pdf_report(self): print(f"PDF: self
class EmployeeDiscount(DiscountStrategy): # Extension: No existing code modified def apply(self, amount: float) -> float: return amount * 0.5
class FlyingBird(Bird): @abstractmethod def fly(self, altitude: int): pass
class Penguin(Bird): def move(self): return "Swimming" # No fly method. Substitutable for Bird. Clients should not be forced to depend on methods they do not use. Deep Dive Issue: Python has no explicit interface keyword. We use Protocol (PEP 544) or multiple ABCs . Fat protocols lead to NotImplementedError stubs. Clients should not be forced to depend on
from typing import Protocol class Printer(Protocol): def print(self, doc: str) -> None: ...
class StandardDiscount(DiscountStrategy): def apply(self, amount: float) -> float: return amount * 0.9
class Fax(Protocol): def fax(self, doc: str) -> None: ... class SimplePrinter: def print(self, doc: str) -> None: print(f"Printing doc") Multi-function device can compose multiple protocols class MultiFunctionDevice(Printer, Scanner, Fax): def print(self, doc): ... def scan(self, doc): ... def fax(self, doc): ... 5. D: Dependency Inversion Principle (DIP) Depend on abstractions, not concretions. High-level modules should not depend on low-level modules. Deep Dive Issue: Python's dynamic imports and global singletons (e.g., requests.get , open ) often hard-code dependencies, making unit testing impossible.
This is an excellent topic. is the cornerstone of maintainable, scalable Object-Oriented Programming. In the context of Python 3: Deep Dive (Part 4) , we move beyond basic syntax into how these principles interact with Python’s dynamic nature, descriptors, metaclasses, and Abstract Base Classes (ABCs).
Here is a deep technical breakdown of applying principles in advanced Python OOP. 1. S: Single Responsibility Principle (SRP) A class should have only one reason to change. Deep Dive Issue: In Python, it's tempting to add save() , load() , or generate_report() methods directly into a data class because of how easy dynamic attributes are.