Python: Abstract Class vs Interface

# Abstract Class in Python

from abc import ABC, abstractmethod

class Animal(ABC):
    """Abstract base class for all animals"""
    
    def __init__(self, name, age):
        self.name = name
        self.age = age
    
    @abstractmethod
    def make_sound(self):
        """Abstract method — must be implemented by subclasses"""
        pass
    
    @abstractmethod
    def move(self):
        """Abstract method — must be implemented by subclasses"""
        pass
    
    # Concrete method — shared by all subclasses
    def get_info(self):
        return f"{self.name} is {self.age} years old"
    
    # Another concrete method
    def sleep(self):
        return f"{self.name} is sleeping"

class Dog(Animal):
    def make_sound(self):
        return "Woof!"
    
    def move(self):
        return f"{self.name} runs on four legs"
    
    # Optional: override the concrete method
    def sleep(self):
        return f"{self.name} is sleeping (curled up)"

class Cat(Animal):
    def make_sound(self):
        return "Meow!"
    
    def move(self):
        return f"{self.name} walks silently"
    
    def sleep(self):
        return f"{self.name} is sleeping (on the couch)"

# Cannot instantiate abstract class
# animal = Animal("Bob", 5)  # TypeError

# But can instantiate subclasses
dog = Dog("Rex", 3)
cat = Cat("Whiskers", 2)

print(dog.get_info())       # Rex is 3 years old
print(dog.make_sound())     # Woof!
print(dog.move())           # Rex runs on four legs
print(dog.sleep())          # Rex is sleeping (curled up)

print(cat.get_info())       # Whiskers is 2 years old
print(cat.make_sound())     # Meow!
print(cat.move())           # Whiskers walks silently

print("\n✅ Abstract classes: can have state, abstract methods, and concrete methods")
print("⚠️ Cannot instantiate the abstract class itself")

# Interfaces in Python — Two Approaches

from abc import ABC, abstractmethod
from typing import Protocol

# -----------------------------
# Approach 1: ABC with only abstract methods
# -----------------------------

class Drawable(ABC):
    """Interface: anything that can be drawn"""
    
    @abstractmethod
    def draw(self):
        """Draw the object — must be implemented"""
        pass
    
    @abstractmethod
    def get_area(self):
        """Return the area — must be implemented"""
        pass

class Circle(Drawable):
    def __init__(self, radius):
        self.radius = radius
    
    def draw(self):
        return f"Drawing a circle with radius {self.radius}"
    
    def get_area(self):
        return 3.14 * self.radius ** 2

class Square(Drawable):
    def __init__(self, side):
        self.side = side
    
    def draw(self):
        return f"Drawing a square with side {self.side}"
    
    def get_area(self):
        return self.side ** 2

# -----------------------------
# Approach 2: Protocol (structural typing)
# -----------------------------

class Renderable(Protocol):
    """Interface: anything that can be rendered"""
    def render(self) -> str: ...
    def get_name(self) -> str: ...

# These classes don't need to inherit from anything
class PDFRenderer:
    def render(self) -> str:
        return "Rendering PDF file"
    
    def get_name(self) -> str:
        return "PDF Renderer"

class HTMLRenderer:
    def render(self) -> str:
        return "Rendering HTML content"
    
    def get_name(self) -> str:
        return "HTML Renderer"

# -----------------------------
# Using both approaches
# -----------------------------

print("=== ABC Interface (Drawable) ===")
circle = Circle(5)
square = Square(4)

print(circle.draw())        # Drawing a circle with radius 5
print(f"Area: {circle.get_area()}")  # Area: 78.5

print(square.draw())        # Drawing a square with side 4
print(f"Area: {square.get_area()}")  # Area: 16

print("\n=== Protocol Interface (Renderable) ===")
def display(renderer: Renderable):
    print(f"{renderer.get_name()}: {renderer.render()}")

display(PDFRenderer())      # PDF Renderer: Rendering PDF file
display(HTMLRenderer())     # HTML Renderer: Rendering HTML content

print("\n✅ Interfaces: pure contract, no state, no implementation")
print("✅ Protocol: classes don't need to inherit from anything")

# Abstract Class vs Interface — Side by Side Comparison

from abc import ABC, abstractmethod
from typing import Protocol

# ----- ABSTRACT CLASS -----
class Vehicle(ABC):
    """Abstract class — can have state and concrete methods"""
    
    def __init__(self, make, model, year):
        self.make = make
        self.model = model
        self.year = year
        self.speed = 0
    
    @abstractmethod
    def start_engine(self):
        """Abstract method — must be implemented"""
        pass
    
    @abstractmethod
    def stop_engine(self):
        """Abstract method — must be implemented"""
        pass
    
    # Concrete method — shared behavior
    def accelerate(self, amount):
        self.speed += amount
        return f"Accelerating to {self.speed} km/h"
    
    # Concrete method — shared behavior
    def get_info(self):
        return f"{self.make} {self.model} ({self.year})"

class Car(Vehicle):
    def start_engine(self):
        return "Car engine started with key"
    
    def stop_engine(self):
        return "Car engine stopped"

class Motorcycle(Vehicle):
    def start_engine(self):
        return "Motorcycle engine started with kick"
    
    def stop_engine(self):
        return "Motorcycle engine stopped"


# ----- INTERFACE (using ABC with only abstract methods) -----
class Drivable(ABC):
    """Interface — pure contract, no state, no concrete methods"""
    
    @abstractmethod
    def drive(self, distance):
        pass
    
    @abstractmethod
    def brake(self):
        pass

class Sedan(Drivable):
    def __init__(self, make, model):
        self.make = make
        self.model = model
    
    def drive(self, distance):
        return f"Driving {distance} km in sedan"
    
    def brake(self):
        return "Applying brakes in sedan"

class SUV(Drivable):
    def __init__(self, make, model):
        self.make = make
        self.model = model
    
    def drive(self, distance):
        return f"Driving {distance} km in SUV"
    
    def brake(self):
        return "Applying brakes in SUV"


# ----- INTERFACE (using Protocol) -----
class Brakeable(Protocol):
    """Interface — structural typing"""
    def brake(self) -> str: ...

def apply_emergency_brake(vehicle: Brakeable):
    print(f"⚠️ EMERGENCY: {vehicle.brake()}")

# Both Sedan and SUV work with the Protocol
car1 = Sedan("Toyota", "Camry")
car2 = SUV("Honda", "CR-V")
apply_emergency_brake(car1)  # Applying brakes in sedan
apply_emergency_brake(car2)  # Applying brakes in SUV


# ----- COMPARISON SUMMARY -----
print("\n" + "=" * 60)
print("ABSTRACT CLASS vs INTERFACE")
print("=" * 60)

print("\n| Feature              | Abstract Class        | Interface             |")
print("|----------------------|-----------------------|-----------------------|")
print("| State (variables)    | ✅ Yes                | ❌ No                 |")
print("| Concrete methods     | ✅ Yes                | ❌ No                 |")
print("| Abstract methods     | ✅ Yes                | ✅ Yes                |")
print("| Instantiable?        | ❌ No                 | ❌ No                 |")
print("| Multiple inheritance | ❌ Usually one        | ✅ Yes                |")
print("| Use case             | Share code & state    | Define contract       |")
print("| Python tools         | abc.ABC, @abstractmethod | abc.ABC or Protocol |")

print("\n✅ Abstract class: 'IS-A' relationship (what something IS)")
print("✅ Interface: 'CAN-DO' relationship (what something CAN DO)")

# When to Use Abstract Class vs Interface

# ----- USE ABSTRACT CLASS WHEN -----

# 1. You need to share common code among related classes
class Shape(ABC):
    def __init__(self, color):
        self.color = color
    
    @abstractmethod
    def area(self):
        pass
    
    # Concrete method — shared by all shapes
    def get_color(self):
        return self.color

class Rectangle(Shape):
    def __init__(self, color, width, height):
        super().__init__(color)
        self.width = width
        self.height = height
    
    def area(self):
        return self.width * self.height

# ✅ Abstract class: Rectangle IS-A Shape, shares color state and get_color()


# 2. You want to provide a default implementation
class Writer(ABC):
    @abstractmethod
    def write(self, content):
        pass
    
    # Default implementation that can be overridden
    def write_line(self, content):
        return self.write(content + "\n")

class FileWriter(Writer):
    def write(self, content):
        return f"Writing: {content}"

class ConsoleWriter(Writer):
    def write(self, content):
        return f"Console: {content}"

# ✅ Abstract class: provides default write_line() that uses write()


# ----- USE INTERFACE WHEN -----

# 1. You want to define a contract for unrelated classes
class Flyable(ABC):
    @abstractmethod
    def fly(self):
        pass

class Bird:
    def fly(self):
        return "Bird flies"

class Airplane:
    def fly(self):
        return "Airplane flies"

# ✅ Interface: Bird and Airplane are unrelated but both CAN-DO fly()


# 2. You want multiple inheritance (implement multiple interfaces)
class Swimmable(ABC):
    @abstractmethod
    def swim(self):
        pass

class Amphibian(Flyable, Swimmable):
    def fly(self):
        return "Amphibian flies"
    
    def swim(self):
        return "Amphibian swims"

# ✅ Interface: multiple inheritance is clean and safe


# ----- USE PROTOCOL (modern interface) WHEN -----

# 3. You want loose coupling (class doesn't depend on your interface)
class Serializer(Protocol):
    def serialize(self) -> str: ...

class JSONData:
    def serialize(self) -> str:
        return '{"data": "json"}'

class XMLData:
    def serialize(self) -> str:
        return "xml"

def save(data: Serializer):
    print(f"Saving: {data.serialize()}")

# ✅ Protocol: classes don't need to import or inherit from Serializer

print("""
| Use Case                          | Abstract Class | Interface (ABC) | Protocol |
|-----------------------------------|----------------|-----------------|----------|
| Share code & state               | ✅ Yes         | ❌ No           | ❌ No     |
| Define contract for related classes | ✅ Yes     | ✅ Yes          | ✅ Yes    |
| Define contract for unrelated classes | ❌ No  | ✅ Yes          | ✅ Yes    |
| Multiple inheritance             | ❌ No          | ✅ Yes          | ✅ Yes    |
| Loose coupling (no dependency)   | ❌ No          | ❌ No           | ✅ Yes    |
| Runtime enforcement              | ✅ Yes         | ✅ Yes          | ❌ No*    |
| Static type checking             | ✅ Yes         | ✅ Yes          | ✅ Yes    |
| Default implementations          | ✅ Yes         | ❌ No           | ❌ No     |
""")

print("* Protocols can use @runtime_checkable for runtime checks")

# Real-World Example: Payment Processing System

from abc import ABC, abstractmethod
from typing import Protocol
import json

# ============================================================
# Part 1: ABSTRACT CLASS — Base Payment Processor
# ============================================================

class PaymentProcessor(ABC):
    """Abstract class for all payment processors"""
    
    def __init__(self, merchant_id: str):
        self.merchant_id = merchant_id
        self.transactions = []
    
    @abstractmethod
    def process_payment(self, amount: float, currency: str) -> dict:
        """Process a payment — must be implemented"""
        pass
    
    @abstractmethod
    def refund_payment(self, transaction_id: str) -> dict:
        """Refund a payment — must be implemented"""
        pass
    
    # Concrete method — shared by all processors
    def get_transaction_history(self):
        return self.transactions
    
    # Concrete method — shared by all processors
    def add_transaction(self, transaction):
        self.transactions.append(transaction)
        return transaction

class StripeProcessor(PaymentProcessor):
    def process_payment(self, amount: float, currency: str) -> dict:
        transaction = {
            "id": f"stripe_{len(self.transactions) + 1}",
            "amount": amount,
            "currency": currency,
            "status": "succeeded",
            "processor": "Stripe"
        }
        self.add_transaction(transaction)
        return transaction
    
    def refund_payment(self, transaction_id: str) -> dict:
        return {
            "id": f"refund_{transaction_id}",
            "status": "refunded",
            "processor": "Stripe"
        }

class PayPalProcessor(PaymentProcessor):
    def process_payment(self, amount: float, currency: str) -> dict:
        transaction = {
            "id": f"paypal_{len(self.transactions) + 1}",
            "amount": amount,
            "currency": currency,
            "status": "completed",
            "processor": "PayPal"
        }
        self.add_transaction(transaction)
        return transaction
    
    def refund_payment(self, transaction_id: str) -> dict:
        return {
            "id": f"refund_{transaction_id}",
            "status": "refunded",
            "processor": "PayPal"
        }

# ============================================================
# Part 2: INTERFACE — Notification System (Protocol)
# ============================================================

class Notifier(Protocol):
    """Protocol for notification senders"""
    def send(self, message: str, recipient: str) -> dict: ...
    def get_status(self) -> str: ...

# These classes don't know about the Notifier protocol

class EmailNotifier:
    def send(self, message: str, recipient: str) -> dict:
        return {
            "status": "sent",
            "recipient": recipient,
            "message": message[:20] + "...",
            "method": "email"
        }
    
    def get_status(self) -> str:
        return "Email service: healthy"

class SMSNotifier:
    def send(self, message: str, recipient: str) -> dict:
        return {
            "status": "sent",
            "recipient": recipient,
            "message": message[:15] + "...",
            "method": "sms"
        }
    
    def get_status(self) -> str:
        return "SMS service: healthy"

class PushNotifier:
    def send(self, message: str, recipient: str) -> dict:
        return {
            "status": "delivered",
            "recipient": recipient,
            "message": message[:10] + "...",
            "method": "push"
        }
    
    def get_status(self) -> str:
        return "Push service: healthy"

# ============================================================
# Part 3: USING THE SYSTEM
# ============================================================

def process_order(amount: float, currency: str, 
                  processor: PaymentProcessor, 
                  notifiers: list):
    """Process an order with payment and notifications"""
    
    # Process payment (using abstract class)
    result = processor.process_payment(amount, currency)
    print(f"💰 Payment: {result}")
    
    # Send notifications (using protocol)
    for notifier in notifiers:
        status = notifier.get_status()
        if "healthy" in status or "delivered" in status:
            notification = notifier.send(
                f"Your payment of {amount} {currency} was processed",
                "customer@example.com"
            )
            print(f"📨 {notification}")
    
    return result

# Demo
print("=" * 60)
print("PAYMENT PROCESSING SYSTEM")
print("=" * 60)

stripe = StripeProcessor("merchant_001")
paypal = PayPalProcessor("merchant_002")

notifiers = [EmailNotifier(), SMSNotifier(), PushNotifier()]

print("\n1. Processing with Stripe")
process_order(99.99, "USD", stripe, notifiers)

print("\n2. Processing with PayPal")
process_order(49.95, "EUR", paypal, notifiers)

print("\n3. Transaction History")
print(f"Stripe transactions: {stripe.get_transaction_history()}")
print(f"PayPal transactions: {paypal.get_transaction_history()}")

print("\n✅ Abstract class: PaymentProcessor provides shared state and methods")
print("✅ Protocol: Notifier allows any class with send() and get_status()")

# Best Practices for Abstract Classes and Interfaces

from abc import ABC, abstractmethod
from typing import Protocol

# ============================================================
# 1. ABSTRACT CLASS BEST PRACTICES
# ============================================================

# ✅ DO: Use abstract classes for related classes with shared code
class Animal(ABC):
    def __init__(self, name):
        self.name = name
    
    @abstractmethod
    def speak(self):
        pass
    
    # Shared concrete method
    def get_name(self):
        return self.name

# ❌ DON'T: Use abstract class for unrelated classes
# class Printable(ABC):  # This should be an interface
#     @abstractmethod
#     def print(self):
#         pass


# ============================================================
# 2. INTERFACE BEST PRACTICES
# ============================================================

# ✅ DO: Keep interfaces focused (single responsibility)
class Printable(ABC):
    @abstractmethod
    def print(self):
        pass

class Serializable(ABC):
    @abstractmethod
    def serialize(self):
        pass

# ❌ DON'T: Put unrelated methods in one interface
# class Everything(ABC):
#     @abstractmethod
#     def print(self):
#         pass
#     @abstractmethod
#     def serialize(self):
#         pass
#     @abstractmethod
#     def save(self):
#         pass


# ============================================================
# 3. MIXING ABSTRACT CLASSES AND INTERFACES
# ============================================================

# ✅ DO: Use abstract class for core behavior and interfaces for additional capabilities
class Document(ABC):
    """Abstract class: core document behavior"""
    def __init__(self, title):
        self.title = title
    
    @abstractmethod
    def open(self):
        pass
    
    @abstractmethod
    def close(self):
        pass

class Printable:
    """Interface: can be printed"""
    def print(self):
        return f"Printing {self.title}"

class Exportable:
    """Interface: can be exported"""
    def export(self):
        return f"Exporting {self.title}"

class PDFDocument(Document, Printable):
    def open(self):
        return f"Opening PDF: {self.title}"
    
    def close(self):
        return f"Closing PDF: {self.title}"

class WordDocument(Document, Printable, Exportable):
    def open(self):
        return f"Opening Word: {self.title}"
    
    def close(self):
        return f"Closing Word: {self.title}"


# ============================================================
# 4. INTERFACE NAMING CONVENTIONS
# ============================================================

# ✅ DO: Use clear names — suffix with "-able" for capabilities
class Playable(ABC):
    """Interface: something that can be played"""
    @abstractmethod
    def play(self):
        pass

class Stoppable(ABC):
    """Interface: something that can be stopped"""
    @abstractmethod
    def stop(self):
        pass

# ❌ DON'T: Use vague names
# class Doer(ABC):
#     pass


# ============================================================
# 5. PROTOCOL BEST PRACTICES
# ============================================================

# ✅ DO: Use Protocols for loose coupling
class Logger(Protocol):
    def log(self, message: str) -> None: ...

class FileLogger:
    def log(self, message: str) -> None:
        print(f"File: {message}")

class ConsoleLogger:
    def log(self, message: str) -> None:
        print(f"Console: {message}")

# ✅ DO: Use Protocols for public APIs
class Cache(Protocol):
    def get(self, key: str) -> object: ...
    def set(self, key: str, value: object) -> None: ...


# ============================================================
# 6. SUMMARY
# ============================================================

print("""
📋 BEST PRACTICES SUMMARY
========================

ABSTRACT CLASS:
• Use for closely related classes
• Share code and state
• Use single inheritance
• Name clearly (Animal, PaymentProcessor, etc.)

INTERFACE (ABC):
• Use for unrelated classes
• Define contract only (no state, no implementation)
• Support multiple inheritance
• Name with "-able" suffix (Printable, Serializable)

INTERFACE (PROTOCOL):
• Use for loose coupling
• Class doesn't depend on the interface
• Use for structural typing
• Great for public APIs and third-party code

MIXING:
• Abstract class for core behavior
• Interfaces for additional capabilities
• Both can be used in the same class
""")