Loose vs. Tight Coupling in Python: Absolute Beginners Tutorial

When two parts of your code are inseparable, changing one part forces you to change the other. That is tight coupling. When the same two parts can change independently, that is loose coupling. Learning to tell the difference — and knowing which to use — is one of the skills that separates workable Python code from fragile Python code.

Think of coupling as the degree to which one piece of code relies on the internal details of another. High coupling means the two pieces know too much about each other. Low coupling means they communicate only through a simple, well-defined interface and do not care what is happening on the other side. This concept applies whether you are writing functions, classes, or whole modules.

What Coupling Means in Python

In Python, coupling appears most clearly when one class creates an instance of another class directly inside itself. That act of creation locks the two classes together. The class doing the creating now depends on a specific other class — its name, its constructor signature, its behavior. If the other class changes, the first class breaks.

Coupling is not inherently bad. Some coupling is unavoidable, and some is intentional. The goal is not to eliminate all coupling but to make sure dependencies are explicit, limited, and easy to replace. When coupling is too tight, your code becomes difficult to test, difficult to extend, and difficult to hand off to someone else.

Python makes it easy to write tightly coupled code by accident, especially when you are learning. The language does not enforce any separation by default. You can call any class from any other class with no warnings. That freedom is powerful, but it means the responsibility for keeping dependencies manageable falls entirely on the programmer.

Tight Coupling Up Close

Here is a common example of tight coupling. A Notifier class wants to send messages. To do that it needs an EmailSender object. The tightly coupled version creates that EmailSender inside its own constructor:

# Tight coupling example
class EmailSender:
    def send(self, message):
        print(f"Sending email: {message}")


class Notifier:
    def __init__(self):
        # Notifier creates its own EmailSender — tightly coupled
        self.sender = EmailSender()

    def notify(self, message):
        self.sender.send(message)


notifier = Notifier()
notifier.notify("Your order has shipped.")

This looks fine at first glance. It works. But consider what happens when requirements change. What if you need to send SMS messages instead of emails? You would have to open the Notifier class and change the line that creates EmailSender. Then what if you need to test Notifier without actually sending emails? You cannot, because the email sender is buried inside the class and you have no way to replace it.

Another sign of tight coupling is when changing the name or constructor of EmailSender requires you to update every class that instantiates it. That ripple effect is one of the most common sources of bugs in growing codebases.

Loose Coupling Up Close

The loosely coupled version of the same code does not create its own EmailSender. Instead, it receives a sender object from the outside. This pattern is called dependency injection.

# Loose coupling example — dependency injection
class EmailSender:
    def send(self, message):
        print(f"Sending email: {message}")


class SmsSender:
    def send(self, message):
        print(f"Sending SMS: {message}")


class Notifier:
    def __init__(self, sender):
        # The sender is passed in — loosely coupled
        self.sender = sender

    def notify(self, message):
        self.sender.send(message)


# Pass in whichever sender you need
email_notifier = Notifier(EmailSender())
email_notifier.notify("Your order has shipped.")

sms_notifier = Notifier(SmsSender())
sms_notifier.notify("Your order has shipped.")

Notifier no longer knows or cares what kind of sender it has. It only knows that the sender has a send method. This is Python's duck typing in action: if the object passed in has a send method, it works. No inheritance required, no formal interface declaration required.

Here is what a test-friendly fake sender looks like:

# A fake sender used in tests — no real messages are sent
class FakeSender:
    def __init__(self):
        self.sent = []

    def send(self, message):
        self.sent.append(message)


# Test without side effects
fake = FakeSender()
notifier = Notifier(fake)
notifier.notify("Test message")

assert fake.sent == ["Test message"]
print("Test passed.")

This works because Notifier does not check the type of its sender. It calls .send() and trusts that the method exists. FakeSender has that method, so it works perfectly in tests.

Comparing the Two Approaches

The table below summarizes how tight coupling and loose coupling compare across the qualities that matter to a working programmer. Tap any row to expand the detail.

Loose Coupling with Functions as Arguments

Loose coupling does not only apply to classes. Functions can be loosely coupled too. Instead of calling a specific function by name, you pass the function in as an argument. This is a common Python pattern and is even simpler than class-based injection.

# Tightly coupled: process() always writes to a file
def process_tight(data):
    with open("output.txt", "w") as f:
        f.write(str(data))


# Loosely coupled: process() uses whatever writer you give it
def process_loose(data, writer):
    writer(str(data))


# Use it with a real file writer
def file_writer(content):
    with open("output.txt", "w") as f:
        f.write(content)


# Use it with a test writer that does nothing
def null_writer(content):
    pass  # Used in tests — no file created


process_loose("hello", file_writer)   # writes to file
process_loose("hello", null_writer)   # does nothing — safe for tests
process_loose("hello", print)         # prints to console

Passing print directly as the writer is a useful debugging trick. Python functions are first-class objects, meaning they can be passed around just like any other value. This flexibility makes function-based loose coupling feel natural in Python.

"Explicit is better than implicit." — The Zen of Python, Tim Peters

That principle applies directly here. Loose coupling makes dependencies explicit by putting them in the function signature or class constructor, where they are visible to every caller and readable by every developer.

Python Learning Summary Points

1. Tight coupling occurs when a class creates its own dependencies inside itself. Loose coupling occurs when dependencies are passed in from the outside.
2. Dependency injection is the most common technique for achieving loose coupling in Python. Pass objects or callables into constructors or functions rather than creating them internally.
3. Python's duck typing supports loose coupling naturally. A class does not need to know the type of its dependency — only that the dependency has the methods it needs.
4. Loosely coupled code is easier to test because you can substitute fake objects for real ones. Tightly coupled code forces real dependencies to run during tests.
5. Loose coupling does not mean zero coupling. Some coupling is necessary and correct. The goal is to make dependencies explicit, limited in scope, and substitutable.

Coupling is one of those design concepts that clicks once you have seen it cause a real problem. A class that was simple to write becomes a headache to change, and when you trace the problem back, you find a hard-coded dependency buried six layers deep. Starting to think about coupling early — even in small projects — builds habits that pay off as code grows.