What Does Tightly Coupled Mean in Python? Absolute Beginners Tutorial

Tightly coupled code means two pieces of a program depend so heavily on each other's internal details that changing one forces changes in the other. This tutorial explains what that means, shows every major form it takes in Python — from hard-wired constructors and inheritance to global state — and walks through how to fix each one.

No prior knowledge of design patterns is assumed. By the end, you will be able to look at a Python class and identify whether it is tightly or loosely coupled — and know exactly what to do about it.

What Coupling Means

Coupling is a measure of how much one piece of code knows about — and depends on — another piece of code. At one extreme, two parts of a program are completely independent and could be moved to separate projects without either noticing. At the other extreme, two parts are so intertwined that they are effectively one piece of code split across two files.

In any real codebase, some coupling is unavoidable. A Cart class that adds products to a shopping list has to know something about what a product is. The question is: how much does it need to know? A class that knows it needs something with a save method is fine. A class that knows it specifically needs a Database constructed with no arguments is the start of a problem.

Tight coupling is the situation where one part of your code reaches into the private internal workings of another part — knowing its exact class name, its internal variable structure, or how it does its job rather than just what it produces. When that internal detail changes, both sides break.

Loose coupling is the opposite: one part communicates with another through a clear, stable boundary — a defined method signature, a shared interface, or a simple function parameter. The internal details on either side can change freely as long as that boundary stays consistent.

What Tight Coupling Looks Like in Python

The clearest example of tight coupling is a class that creates another class inside its own constructor. Here is a straightforward version:

# Tightly coupled — Order creates its own Database
class Database:
    def save(self, data):
        print(f"Saving {data} to database")

class Order:
    def __init__(self):
        self.db = Database()   # hard-wired dependency

    def place(self, item):
        self.db.save(item)

Notice that Order.__init__ calls Database() directly. Order now has three hard-wired facts about Database: its exact class name, the fact that it takes no constructor arguments, and the assumption that it will always be there. If any of those facts changes — say you rename the class, add a required argument, or want to switch to a different storage system during testing — Order breaks along with it.

The accordion below compares the same three patterns so you can see how the dependency relationship changes across tight coupling, constructor injection, and a protocol.

Why Tight Coupling Creates Real Problems

Tight coupling is not just a style concern. It creates three concrete obstacles as a codebase grows, and each one compounds the others.

Testing becomes difficult. When a class creates its own dependencies internally, you cannot isolate it. Testing Order from the example above means you also invoke real Database logic. If the database is slow, unavailable, or writes to real storage during a test, your test suite becomes fragile and slow.

Reuse is blocked. Suppose a second part of the same application needs to place orders but write them to a file instead of a database — perhaps for an audit log or an offline export. With the tightly coupled version, that is impossible without duplicating or rewriting Order. The class and its storage mechanism are one fused unit. With dependency injection, you pass a different storage object and the same Order class handles both cases without a single line of it changing.

Change propagates unpredictably. A modification to the internal structure of Database — even something as small as renaming a private method — forces you to trace every class that created a Database instance and check whether it is affected.

Here is a demonstration of the testing problem. Notice how the tightly coupled version has no seam where a fake can be inserted:

# Tightly coupled — no way to swap in a fake database during tests
class Order:
    def __init__(self):
        self.db = Database()   # always uses the real Database

# Loosely coupled — pass in whatever you like
class Order:
    def __init__(self, db):
        self.db = db           # caller decides

# In a test you can now do:
class FakeStorage:
    def save(self, data):
        self.saved = data      # records what was saved without touching disk

order = Order(FakeStorage())
order.place("bicycle")
assert order.db.saved == "bicycle"

The loosely coupled version lets you write a FakeStorage class in your test file and pass it straight in. The tightly coupled version has no such entry point.

The adapter pattern: shielding your code from third-party interfaces

An adapter is a wrapper class that translates between your code's interface and a third-party library's interface. Your business classes depend only on the adapter's interface — which you define and control — so the library's internals never reach into your code. Step four above mentions this pattern. Here is what it looks like in Python.

from __future__ import annotations
from typing import Protocol

# Your Protocol — the contract your code depends on
class FileStore(Protocol):
    def upload(self, key: str, data: bytes) -> None: ...

# Third-party library class you do not control
class boto3S3Client:
    def put_object(self, Bucket, Key, Body): ...   # their naming, not yours

# Adapter: wraps the library, satisfies your Protocol
class S3Adapter:
    def __init__(self, client: boto3S3Client, bucket: str) -> None:
        self._client = client
        self._bucket = bucket

    def upload(self, key: str, data: bytes) -> None:
        # translate your interface into the library's interface
        self._client.put_object(Bucket=self._bucket, Key=key, Body=data)

# Your business class only knows about FileStore — never boto3
class AssetManager:
    def __init__(self, store: FileStore) -> None:
        self.store = store

    def save_asset(self, name: str, content: bytes) -> None:
        self.store.upload(name, content)

# Composition root — only place boto3 is named
client = boto3S3Client()
store = S3Adapter(client, bucket="my-assets")
manager = AssetManager(store)

# For tests — no AWS credentials needed
class LocalStore:
    def __init__(self): self.files: dict[str, bytes] = {}
    def upload(self, key: str, data: bytes) -> None:
        self.files[key] = data

manager_test = AssetManager(LocalStore())

If AWS changes the put_object signature in a future boto3 release, only S3Adapter needs updating. AssetManager does not exist as far as boto3 is concerned, and boto3 does not exist as far as AssetManager is concerned. The adapter is the only place those two worlds touch.

Decoupling side effects with callbacks

When a class triggers a side effect — logging a purchase, sending a notification, recording a metric — the naive solution is to call those services directly. That introduces three coupling points where one business operation existed. The cleaner approach is to accept a list of callable hooks at construction time and call them after the business action completes.

from __future__ import annotations
from typing import Callable

# Order knows nothing about loggers, mailers, or metrics
class Order:
    def __init__(
        self,
        db,
        on_placed: list[Callable[[str], None]] | None = None
    ) -> None:
        self.db = db
        self._on_placed = on_placed or []

    def place(self, item: str) -> None:
        self.db.save(item)
        for handler in self._on_placed:
            handler(item)   # fire every registered callback

# Individual side-effect functions — fully independent
def log_order(item: str) -> None:
    print(f"[LOG] Order placed: {item}")

def send_confirmation(item: str) -> None:
    print(f"[EMAIL] Confirmation sent for: {item}")

def record_metric(item: str) -> None:
    print(f"[METRIC] +1 order: {item}")

# Composition root: wire side effects without touching Order
order = Order(
    db=real_db,
    on_placed=[log_order, send_confirmation, record_metric]
)
order.place("notebook")

# Test: no side effects at all — pass an empty list or a recorder
received: list[str] = []
order_test = Order(db=FakeDb(), on_placed=[received.append])
order_test.place("notebook")
assert received == ["notebook"]

Adding a fourth side effect later — say, triggering a warehouse pick list — requires only adding a new function and registering it at the composition root. Order does not change at all. This is the same decoupling principle as dependency injection, applied to side effects rather than collaborators.

from __future__ import annotations
from typing import Protocol

# Step 3: define only the contract you need
class Storage(Protocol):
    def save(self, data: str) -> None: ...

# Order depends on the Protocol, not on any concrete class
class Order:
    def __init__(self, db: Storage) -> None:
        self.db = db

    def place(self, item: str) -> None:
        self.db.save(item)

# Production usage
class PostgresDatabase:
    def save(self, data: str) -> None:
        print(f"Persisting {data!r} to Postgres")

# Test usage — no Postgres needed
class InMemoryStorage:
    def __init__(self):
        self.records: list[str] = []
    def save(self, data: str) -> None:
        self.records.append(data)

order = Order(InMemoryStorage())
order.place("notebook")
print(order.db.records)   # ['notebook']

"Program to an interface, not an implementation." — Gamma, Helm, Johnson & Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software (Addison-Wesley, 1995), p. 18

That principle — from the book published in October 1994 with a 1995 copyright, by the authors now known as the Gang of Four — is exactly what dependency injection and typing.Protocol make possible in Python. Your class programs to a description of what it needs — a save method — rather than to a concrete PostgresDatabase class. The concrete class can be swapped at any point without touching the class that depends on it.

Protocol vs. Abstract Base Class: which should you use?

Python offers two ways to define a shared interface: typing.Protocol and abc.ABC. They solve the same problem differently.

For beginners reducing tight coupling, either works. typing.Protocol is the more Pythonic and flexible choice for interfaces you define yourself. Use abc.ABC when you want Python to loudly break at runtime if a required method is missing.

# Step 1 — non-breaking: add an optional parameter
# All existing callers still work unchanged
class Order:
    def __init__(self, db=None):
        self.db = db or Database()   # fallback keeps production working

# Step 2 — tests can now inject a fake immediately
class FakeDb:
    def __init__(self): self.saved = []
    def save(self, data): self.saved.append(data)

order = Order(db=FakeDb())   # test passes a fake, no patch needed

# Step 3 — migrate call sites one by one
# Before: order = Order()
# After:  order = Order(db=real_database)

# Step 4 — remove the default, construction lives only in main.py
class Order:
    def __init__(self, db):   # no default, no fallback — fully decoupled
        self.db = db

Where Do You Actually Create the Objects? The Composition Root

When beginners first learn dependency injection, a natural question appears: if the class no longer creates its own dependencies, who does? The answer is the composition root — a single place in your program (usually main.py or your application factory) where all concrete objects are created and wired together.

This is not just a convention. Centralising all construction in one place means that changing a dependency — say, swapping a Postgres database for SQLite in a test environment — requires only a one-line change in the composition root rather than hunting through every class that touches the database.

# composition_root.py  — the ONLY place concrete classes are named
from __future__ import annotations
from typing import Protocol

class Storage(Protocol):
    def save(self, data: str) -> None: ...

class PostgresStorage:
    def save(self, data: str) -> None:
        print(f"Persisting {data!r} to Postgres")

class InMemoryStorage:
    def __init__(self):
        self.records: list[str] = []
    def save(self, data: str) -> None:
        self.records.append(data)

class Order:
    def __init__(self, db: Storage) -> None:
        self.db = db
    def place(self, item: str) -> None:
        self.db.save(item)

class ReportGenerator:
    def __init__(self, db: Storage) -> None:
        self.db = db
    def run(self, label: str) -> None:
        self.db.save(f"report:{label}")

def build_app(use_real_db: bool = True):
    """Composition root: all concrete decisions live here."""
    storage = PostgresStorage() if use_real_db else InMemoryStorage()
    # Every class receives the same storage object — wired once
    return Order(storage), ReportGenerator(storage)

# Production
order, report = build_app(use_real_db=True)
order.place("bicycle")

# Test / CI environment — zero database required
order_test, report_test = build_app(use_real_db=False)
order_test.place("bicycle")
print(order_test.db.records)   # ['bicycle']

Notice that Order and ReportGenerator never mention PostgresStorage or InMemoryStorage by name. The entire swap between environments happens in one function. That is the practical payoff of eliminating tight coupling.

When Tight Coupling Is Acceptable

Not all coupling is a problem worth solving. In Python, there are several common cases where tight coupling between two things is the correct, intentional choice.

Value objects and dataclasses. A @dataclass that represents a product with a name and price is fully coupled to those two fields. That is its entire job. Injecting the price type through a Protocol would be over-engineering. The coupling is stable, intentional, and contained.

Classes that only contain data. If a class has no external side effects — it performs no I/O, makes no network calls, and writes to no shared state — the risk of tight coupling is low. You can still test it without substituting anything, because there is nothing to substitute.

Internal implementation details. When a public class uses a private helper class that is never exposed outside its own module, the coupling between them is a private implementation concern. If both classes change together, that is acceptable — they are one logical unit split across two objects for clarity.

Enumerations. A class that accepts an Enum value as a parameter and switches on it is tightly coupled to that enum. This is usually correct: enums are stable, version-controlled, and part of the public interface you intended to expose.

The practical rule: tight coupling between two things in the same layer and module, where neither thing needs to be swapped or tested in isolation, is usually fine. Tight coupling across layers — where a high-level business class hardcodes a low-level infrastructure class — is where problems appear.

Coupling in Functions, Not Just Classes

Classes are the most common place to find tight coupling, because constructors make the dependency creation visible. But the same principle applies to plain functions. A function that calls another function by name, rather than accepting a callable as an argument, is tightly coupled to that specific function.

import smtplib

def notify_user(email):
    # hard-wired to SMTP — cannot
    # be tested without a mail server
    server = smtplib.SMTP("smtp.example.com")
    server.sendmail("[email protected]",
                    email, "Hello")

def notify_user(email, send_fn):
    # caller provides any callable
    # — a real mailer or a test stub
    send_fn(email, "Hello")

# Production:
notify_user(email, real_send)

# Test — no SMTP needed:
notify_user(email, lambda e, m: None)

The loosely coupled version accepts a send_fn callable. In production, you pass in a real sending function. In a test, you pass in a lambda that does nothing, records what it received, or raises an intentional error. No mocking framework is required — just a function argument.

Python's functools.partial makes this pattern practical without verbosity. If a function needs a preconfigured callable with some arguments already bound, partial creates it at the composition root:

from functools import partial

def send_email(host, port, from_addr, to_addr, message):
    print(f"Sending via {host}:{port} to {to_addr} — {message}")

# Composition root: bind the infrastructure details once
configured_send = partial(send_email, "smtp.example.com", 587, "[email protected]")

# The rest of the codebase only sees a simple two-argument callable
def notify_user(email, send_fn):
    send_fn(email, "Your order has shipped.")

notify_user("[email protected]", configured_send)

Nothing in notify_user knows about SMTP, host names, or ports. Those infrastructure details are bound at one place — the composition root — and injected as a plain callable. This is the function-level equivalent of dependency injection for classes.

Circular Imports as a Coupling Signal

If you have ever seen Python raise ImportError: cannot import name 'X' from partially initialized module 'Y', you have encountered a circular import. Two modules each import from the other, and Python cannot finish loading either one. This error is one of the clearest symptoms of tight coupling across module boundaries.

Circular imports arise when two modules are so intertwined that neither can exist without the other. This is not a Python limitation to work around — it is a design signal telling you that the two modules are doing too much together and should be separated.

# orders.py — imports from notifications.py
from notifications import Notifier

class Order:
    def place(self, item):
        Notifier().send(f"Placed: {item}")

# notifications.py — imports from orders.py  (circular!)
from orders import Order

class Notifier:
    def send(self, message):
        print(message)
        # Notifier is reaching back into Order — why?

The standard resolution is to introduce a shared interface or move the shared concern to a third module that neither depends on the other. If Notifier does not actually need to know about Order, the import can simply be removed. If it does need some data from an order, that data should be passed as a plain value — a string, a number, a dataclass — rather than importing the full Order class.

Tight Coupling and Inheritance

Inheritance is the tightest form of coupling Python offers. When class Dog inherits from class Animal, it does not just depend on Animal's public interface — it depends on every internal attribute, every method implementation, and every future change to the parent class. That is a much deeper dependency than constructor injection.

This is why the principle "favour composition over inheritance" appears so often in software design literature. Composition — where a class holds an instance of another class rather than extending it — gives you the behaviour you need without locking the two classes together at the structural level.

class FileLogger:
    def log(self, msg):
        print(f"[FILE] {msg}")

# Order IS-A FileLogger — deeply coupled
class Order(FileLogger):
    def place(self, item):
        self.log(f"Placed: {item}")

# Cannot swap the logger without
# changing Order's class hierarchy

class FileLogger:
    def log(self, msg):
        print(f"[FILE] {msg}")

# Order HAS-A logger — loosely coupled
class Order:
    def __init__(self, logger):
        self.logger = logger

    def place(self, item):
        self.logger.log(f"Placed: {item}")

# Swap to any logger — no hierarchy change

Inheritance is not always wrong. It makes sense when you genuinely have an is-a relationship that is stable across the lifetime of the codebase — a Square that truly is a Shape, or a HTTPException that truly is an Exception. The warning sign is inheriting purely to get access to another class's methods, with no meaningful is-a relationship. That is tight coupling dressed up as code reuse.

A practical rule: if you find yourself inheriting from a class only to override one method, composition with a typing.Protocol almost always produces a better design. The child class becomes a collaborator rather than a specialisation, and you gain the ability to swap it independently.

Global State as Hidden Coupling

Global variables and module-level singletons are a form of tight coupling that is harder to see than a ClassName() call in a constructor, because the dependency is invisible in the class signature. A class that reads from or writes to a global variable is coupled to every other piece of code that touches that same global — without any of those relationships appearing in a constructor or method parameter.

# globals.py
current_user = None   # global state

# orders.py — reads global without declaring it as a dependency
import globals

class Order:
    def place(self, item):
        # This class is coupled to globals.current_user
        # but nothing in its signature reveals that
        if globals.current_user is None:
            raise ValueError("No user logged in")
        print(f"{globals.current_user} placed: {item}")

The Order class above looks like it only needs an item string — in reality it also depends on globals.current_user being set correctly before it runs. Testing it in isolation requires you to set up and tear down global state around every test, which makes tests order-dependent and brittle. The dependency is real but invisible.

The fix is the same as for any tight coupling — make the dependency explicit:

# No globals — user is an explicit parameter
class Order:
    def __init__(self, user: str) -> None:
        self.user = user

    def place(self, item: str) -> None:
        print(f"{self.user} placed: {item}")

# Dependency visible, injectable, testable
order = Order(user="alice")
order.place("notebook")

mock.patch vs Dependency Injection

When beginners discover that their tightly coupled code is hard to test, a common first instinct is to reach for unittest.mock.patch. This works — it temporarily replaces a name in a module's namespace so the test sees a fake instead of the real object. But it addresses the symptom rather than the underlying design.

from unittest.mock import patch, MagicMock

# The class is still tightly coupled — patch papers over it for the test
class Order:
    def __init__(self):
        self.db = Database()   # hard-wired

def test_order_place():
    mock_db = MagicMock()
    # patch replaces 'Database' in the module namespace during this test only
    with patch('orders.Database', return_value=mock_db):
        order = Order()
        order.place("bicycle")
        mock_db.save.assert_called_once_with("bicycle")

This test passes, but the coupling remains. Anyone reading Order's constructor still cannot tell what it needs without reading the implementation. The test setup is fragile — it depends on knowing the exact import path 'orders.Database', so renaming a module or moving a class silently breaks the patch target. And the test cannot run without understanding how patch works.

Compare to the same test with dependency injection:

class Order:
    def __init__(self, db):
        self.db = db   # injected — dependency visible in the signature

class FakeDb:
    def __init__(self): self.calls = []
    def save(self, data): self.calls.append(data)

def test_order_place():
    fake = FakeDb()
    order = Order(fake)     # no patching, no magic, no import paths
    order.place("bicycle")
    assert fake.calls == ["bicycle"]

Cohesion and Coupling Together

Coupling measures how much one module depends on another. Cohesion measures how focused a single module is on doing one clear job. The two concepts always travel together in software design because a class with low cohesion — one that does many unrelated things — almost always produces high coupling. Each extra job the class does forces it to reach into more external classes to get what it needs.

A class that handles user authentication, sends email, and writes to a database is doing three jobs. To do all three it must know about an email server, a database connection, and a session store. Each of those is a dependency — and each one is a coupling point. Splitting the class into three focused classes, each with one job, typically reduces coupling as a side effect because each smaller class needs far fewer external dependencies.

The Single Responsibility Principle from SOLID — the idea that a class should have only one reason to change — is a practical statement of the same idea. A class with one reason to change has one job. A class with one job needs fewer external dependencies. Fewer external dependencies means lower coupling.

# Low cohesion — one class, three jobs, three dependency coupling points
class UserManager:
    def __init__(self):
        self.db = PostgresDatabase()    # coupling point 1
        self.mailer = SMTPMailer()      # coupling point 2
        self.cache = RedisCache()       # coupling point 3

    def register(self, email, password): ...
    def send_welcome_email(self, email): ...
    def cache_session(self, user_id): ...

# High cohesion — each class has one job, one dependency
class UserRegistrar:
    def __init__(self, db): self.db = db
    def register(self, email, password): ...

class WelcomeMailer:
    def __init__(self, mailer): self.mailer = mailer
    def send(self, email): ...

class SessionCache:
    def __init__(self, cache): self.cache = cache
    def store(self, user_id): ...

Each of the three focused classes above has one constructor parameter. Each can be tested with a single fake. The coupling still exists — each class still depends on something — but the dependencies are explicit, minimal, and swappable. This is what high cohesion produces: lower coupling as a natural consequence.

Temporal Coupling

Most of the coupling discussed so far is structural — one class knows about the internals of another. There is a second, less-discussed form called temporal coupling, which is about when things must happen rather than what they depend on. Two operations are temporally coupled when they must be called in a specific order, and calling them out of sequence produces incorrect or undefined behaviour.

This is common in code that uses initialisation methods separate from the constructor, or that relies on side effects having been applied before a second call is made:

# Temporal coupling — setup() must be called before process()
# Nothing in the interface enforces or communicates this
class DataPipeline:
    def __init__(self):
        self._ready = False
        self._data = None

    def setup(self, data):
        self._data = data
        self._ready = True

    def process(self):
        if not self._ready:
            raise RuntimeError("Call setup() before process()")
        return [d.strip() for d in self._data]

# A caller can easily get the order wrong:
pipeline = DataPipeline()
pipeline.process()   # RuntimeError — nothing warned about the ordering

The problem is that the ordering requirement is hidden inside the implementation. A caller reading the class signature sees two public methods and nothing to indicate which must come first. The coupling is between the two method calls themselves, not between two classes.

The standard fix is to collapse the two-step pattern into construction — accept the data in the constructor so an object can only exist in a ready state. If there are good reasons to keep two steps, use a factory function that enforces the order and returns a fully-configured object:

from __future__ import annotations

# Fix 1 — make the object always ready at construction
class DataPipeline:
    def __init__(self, data: list[str]) -> None:
        self._data = data   # always ready — no separate setup() required

    def process(self) -> list[str]:
        return [d.strip() for d in self._data]

# Fix 2 — if two-step construction is unavoidable, hide it behind a factory
class DataPipeline:
    def __init__(self, data: list[str]) -> None:
        self._data = data

    @classmethod
    def from_raw(cls, raw_data: list[str]) -> "DataPipeline":
        validated = [d for d in raw_data if d.strip()]
        return cls(validated)   # returns a fully configured instance

    def process(self) -> list[str]:
        return [d.strip() for d in self._data]

# Callers have one clear path — no ordering to remember
pipeline = DataPipeline.from_raw(["  hello  ", "", "  world  "])
print(pipeline.process())   # ['hello', 'world']

When Loose Coupling Goes Too Far

Dependency injection is a powerful tool, but it can be over-applied. The question worth asking is: does loosening this coupling actually serve a real need — testability, replaceability, or flexibility — or am I injecting things out of habit?

A constructor that accepts eight parameters is a signal. Sometimes all eight are genuinely needed and independently swappable. More often, it means the class has too many responsibilities (a cohesion problem) or that some of those parameters are configuration values that could be grouped into a settings object, or that some dependencies are never actually swapped in practice and would be simpler as internal implementation details.

# Over-injected — every internal detail has been pushed to the constructor
# The caller now has to know about — and wire — seven different things
class ReportGenerator:
    def __init__(
        self,
        db,
        formatter,
        logger,
        cache,
        auth_checker,
        rate_limiter,
        audit_log,
    ):
        ...

# Signs you may have gone too far:
# 1. Every test needs to create 7 fakes just to instantiate the class
# 2. Most parameters never change between production and test
# 3. Several parameters are always created together as a group

There are three practical ways to reduce an over-injected constructor without re-introducing tight coupling.

Group related configuration into a dataclass. If several parameters are always provided together and none is independently swapped, a @dataclass groups them cleanly and reduces the constructor signature without hiding the dependency.

Ask whether the dependency is ever substituted. If a logger is always the same standard library logging.Logger and you never need to swap it in tests, injecting it adds friction without benefit. Standard library tools that are stable and have no side effects are reasonable candidates to use directly.

Split the class. If the constructor is long because the class does many things, splitting it along responsibility lines usually reduces the injection load on each resulting class naturally.

Summary

1. Tight coupling happens when one piece of code creates or directly references the internal details of another, locking the two together so that changes in one force changes in the other.
2. The clearest form in Python is a class that instantiates another class directly inside its own constructor using SomeClass(), rather than receiving the instance from outside.
3. The simplest remedy is dependency injection: accept the dependency as a constructor parameter and store it. This gives the caller control and gives you a seam — a point where a substitute can be inserted for testing.
4. Using a typing.Protocol to describe what you need rather than naming a specific class is the most flexible approach. Any object with matching methods satisfies it, with no inheritance required.
5. Inheritance is the tightest form of coupling. Favour composition — holding an instance of another class — over inheritance when you need behaviour without a genuine is-a relationship.
6. Global variables create invisible coupling. A class that reads global state has a hidden dependency that does not appear in its constructor and makes tests order-dependent and fragile.
7. High cohesion and low coupling reinforce each other. A class that does one job needs fewer external dependencies, which reduces coupling naturally. The Single Responsibility Principle is a practical route to both.
8. Not all coupling is a problem. Value objects, dataclasses, and private internal helpers are appropriate candidates for tight coupling. The concern is coupling that hides intent, blocks testing, or forces change to propagate through unrelated parts of the codebase.

Once you can identify tight coupling, you will see the refactoring opportunity sitting next to it. In Python, the gap between tightly coupled and loosely coupled code is often just one constructor parameter.

import dis

class Database:
    def save(self, data):
        print(f"Saving {data}")

class TightOrder:
    def __init__(self):
        self.db = Database()   # hard-wired

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

# Disassemble both constructors to see what CPython compiles them to
print("=== TightOrder.__init__ bytecode ===")
dis.dis(TightOrder.__init__)

print("\n=== LooseOrder.__init__ bytecode ===")
dis.dis(LooseOrder.__init__)

# TightOrder output will show a LOAD_GLOBAL for '(NULL + Database)'
# followed by CALL — the dependency name is embedded in the bytecode
#
# LooseOrder output shows only LOAD_FAST for the parameter 'db'
# — no external name lookup required at all
# (Exact opcode names vary by Python version; the distinction remains the same)