dependency injection

[tmanjupriya-lang]

Select Topic Area

Question

Body

wat is dependency injection. scenarios to use dependency injection in python

[Chiragj2003]

hope it will help
What is Dependency Injection?

Dependency Injection (DI) is a way to give a class the things it needs (dependencies) instead of creating them inside the class.
It helps make code easier to test, change, and reuse.

Without Dependency Injection

class Database:
    def connect(self):
        print("Connecting to database...")

class UserService:
    def __init__(self):
        self.db = Database()  # Created inside
    def get_user(self):
        self.db.connect()

🔴 Problem: UserService is tightly linked to Database — hard to test or replace.

With Dependency Injection

class Database:
    def connect(self):
        print("Connecting to database...")

class MockDatabase:
    def connect(self):
        print("Mock database connected")

class UserService:
    def __init__(self, db):
        self.db = db  # Injected
    def get_user(self):
        self.db.connect()

✅ Now you can pass any database you want:

user_service = UserService(Database())
test_service = UserService(MockDatabase())

When to Use

For testing (mock dependencies easily)

To make code flexible and reusable

In frameworks like Flask or FastAPI

In short:
Dependency Injection = pass what you need instead of creating it inside.
➡️ Makes code clean, flexible, and easy to test.

[github-actions[bot]]

🕒 Discussion Activity Reminder 🕒

This Discussion has been labeled as dormant by an automated system for having no activity in the last 60 days. Please consider one the following actions:

1️⃣ Close as Out of Date: If the topic is no longer relevant, close the Discussion as out of date at the bottom of the page.

2️⃣ Provide More Information: Share additional details or context — or let the community know if you've found a solution on your own.

3️⃣ Mark a Reply as Answer: If your question has been answered by a reply, mark the most helpful reply as the solution.

Note: This dormant notification will only apply to Discussions with the Question label. To learn more, see our recent announcement.

Thank you for helping bring this Discussion to a resolution! 💬

[shamnxd]

What is Dependency Injection (DI)?

Dependency Injection is a design pattern where an object receives its dependencies from the outside instead of creating them internally.

In simple terms:

Don’t create what you depend on — get it injected.

This makes code loosely coupled, testable, and easy to maintain.

---

Without Dependency Injection (tight coupling)

class OrderService:
    def __init__(self):
        self.db = Database()  # hard dependency

    def create_order(self, order):
        self.db.save(order)

Problems:

• Hard to test (can’t easily mock Database)
• Changing database requires changing this class
• Tight coupling

---

With Dependency Injection (loose coupling)

class OrderService:
    def __init__(self, db):
        self.db = db  # dependency injected

    def create_order(self, order):
        self.db.save(order)

Usage:

db = Database()
service = OrderService(db)

Benefits:

• Easy to mock dependencies
• More flexible
• Follows SOLID principles

---

Common Scenarios to Use Dependency Injection in Python

1. Unit Testing

Inject mock objects instead of real ones.

class MockDatabase:
    def save(self, data):
        print("Mock save")

service = OrderService(MockDatabase())

---

2. Swapping Implementations

Example: switch between different databases.

class MySQLDatabase:
    def save(self, data): ...

class MongoDatabase:
    def save(self, data): ...

service = OrderService(MySQLDatabase())
# or
service = OrderService(MongoDatabase())

---

3. Configuration-Based Behavior

Inject different services based on environment.

if ENV == "prod":
    db = MySQLDatabase()
else:
    db = SQLiteDatabase()

---

4. Web Frameworks (FastAPI, Flask, Django)

FastAPI has built-in DI:

from fastapi import Depends

def get_db():
    return Database()

@app.get("/items")
def read_items(db=Depends(get_db)):
    return db.fetch_items()

---

5. Following SOLID Principles

DI supports the Dependency Inversion Principle:

High-level modules should not depend on low-level modules.

---

Ways to Implement Dependency Injection in Python

1. Constructor Injection (most common)

2. Function Parameter Injection

3. Setter Injection

4. DI Frameworks (advanced)

   • dependency-injector
   • FastAPI’s Depends

---

When NOT to Use Dependency Injection

• Very small scripts
• One-off programs
• When abstraction adds unnecessary complexity

[github-actions[bot]]

🕒 Discussion Activity Reminder 🕒

This Discussion has been labeled as dormant by an automated system for having no activity in the last 60 days. Please consider one the following actions:

1️⃣ Close as Out of Date: If the topic is no longer relevant, close the Discussion as out of date at the bottom of the page.

2️⃣ Provide More Information: Share additional details or context — or let the community know if you've found a solution on your own.

3️⃣ Mark a Reply as Answer: If your question has been answered by a reply, mark the most helpful reply as the solution.

Note: This dormant notification will only apply to Discussions with the Question label. To learn more, see our recent announcement.

Thank you for helping bring this Discussion to a resolution! 💬

[Twiddllo]

Dependency Injection (DI) = instead of a class creating what it needs inside itself,
you pass the needed stuff (dependencies) from outside.
It makes code easier to test, reuse, and change.

Simple example:

class Database:
    def save(self, data):
        print("saved")

class UserService:
    def __init__(self, db):   # dependency injected
        self.db = db

    def create_user(self, name):
        self.db.save(name)

db = Database()
service = UserService(db)
service.create_user("Ali")

When to use DI in Python:

• Testing → replace real DB/API with mock objects
• Large apps → keep modules loosely coupled
• Multiple implementations → e.g. SQLite vs PostgreSQL
• Config-based services → logging, caching, APIs
• Frameworks → FastAPI, Django services, background workers

Rule of thumb:
If your class creates lots of internal objects or hardcodes services,
dependency injection will usually make your code cleaner and easier to maintain.

[prashantkoirala465]

Dependency Injection, or DI, is a design pattern where a class or function receives the objects it depends on from the outside instead of creating them internally. In simple terms, instead of a class doing self.db = Database() inside its own code, you pass the database object into it. This makes the code more flexible, easier to test, and less tightly coupled.

In Python, you usually do not need a complex framework for DI. The most common and Pythonic way is simply passing dependencies through the constructor or function parameters.

Here is a simple example:

    def __init__(self, repo):
        self.repo = repo  # dependency is injected

    def get_user(self, user_id):
        return self.repo.fetch(user_id)

Now UserService does not care how repo is created. You can pass a real database repository in production, and a fake or mock repository in tests.

Common scenarios where DI is useful in Python:

Testing
You can inject a mock database or API client instead of calling real external services.

Switching environments
For example, using a real payment service in production and a dummy one in development.

Reusable services
Logging, configuration, caching, or database sessions can be injected instead of recreated everywhere.

Larger applications
It keeps your business logic separate from object creation logic, which improves maintainability.

If you are using frameworks like FastAPI, dependency injection is built in using Depends(), which is commonly used for database sessions, authentication, and shared logic.

As a general rule, if creating objects inside your classes makes testing difficult or swapping implementations painful, dependency injection is a good solution.

[paras-chinchalkar]

Dependency Injection (DI) means giving a class or function its dependencies from outside instead of creating them inside. This makes code loosely coupled, testable, and flexible.
Scenarios in Python:

• Injecting a database client (swap real DB with mock for tests).

• Passing a logger instead of hardcoding logging.

• Providing API clients or config objects externally.
  Example:
  class Service:
  def init(self, db, logger):
  self.db = db
  self.logger = logger

  def process(self, data):
  self.logger.info("Processing...")
  self.db.save(data)

[pratikrath126]

Great examples here already! For a modern Python approach (3.8+), I highly recommend using typing.Protocol for your dependencies.

Instead of inheriting from a base abstract class (ABC), Protocols allow you to define the shape of the dependency you need. This decouples your service from the implementation details entirely.

from typing import Protocol

class Database(Protocol):
    def save(self, data: dict) -> None:
        ...

class UserService:
    def __init__(self, db: Database):
        self.db = db  # Type checker ensures 'db' has a .save() method

# Now any class with a .save() method works, no inheritance required!
class PostgresDB:  # Doesn't need to inherit from anything
    def save(self, data: dict):
        print("Saved to Postgres")

service = UserService(PostgresDB())

This is often called Structural Subtyping (duck typing) and makes DI in Python much more flexible compared to rigid Java/C# style inheritance hierarchies.

[MasteraSnackin]

here minimal concerte python examples of dependency injection using plain classes and constructor injection

from abc import ABC, abstractmethod

Abstraction (interface)

class EmailClient(ABC):
@AbstractMethod
def send(self, to: str, subject: str, body: str) -> None:
raise NotImplementedError

One concrete implementation

class SmtpEmailClient(EmailClient):
def init(self, host: str, port: int) -> None:
self._host = host
self._port = port

def send(self, to: str, subject: str, body: str) -> None:
    # Real implementation would talk to SMTP here
    print(f"[SMTP {self._host}:{self._port}] To={to} Subject={subject} Body={body}")

Another implementation for tests

class InMemoryEmailClient(EmailClient):
def init(self) -> None:
self.sent = []

def send(self, to: str, subject: str, body: str) -> None:
    self.sent.append({"to": to, "subject": subject, "body": body})

Service that depends on the abstraction, not a concrete type

class UserService:
def init(self, email_client: EmailClient) -> None:
# Dependency is injected from outside
self._email_client = email_client

def register_user(self, email: str, name: str) -> None:
    # do persistence etc. here
    subject = "Welcome"
    body = f"Hi {name}, thanks for registering."
    self._email_client.send(email, subject, body)

Composition root / manual DI "container"

def create_user_service_for_prod() -> UserService:
email_client = SmtpEmailClient(host="smtp.example.com", port=587)
return UserService(email_client=email_client)

def create_user_service_for_tests() -> tuple[UserService, InMemoryEmailClient]:
fake_email_client = InMemoryEmailClient()
service = UserService(email_client=fake_email_client)
return service, fake_email_client

if name == "main":
# Production usage
service = create_user_service_for_prod()
service.register_user("alice@example.com", "Alice")

# Test usage
test_service, fake_email = create_user_service_for_tests()
test_service.register_user("bob@example.com", "Bob")
assert len(fake_email.sent) == 1
assert fake_email.sent[0]["to"] == "bob@example.com"