Coupling and Cohesion in C#: High Cohesion, Low Coupling

The vocabulary underneath every design principle you've learned so far: how tightly things stick together, and how well things inside one thing belong together.

You've now learned the Single Responsibility Principle, the Open/Closed Principle, Interface Segregation, and Dependency Inversion. Each one felt like a distinct rule with its own example. Here's the thing nobody told you yet: all four of them are really techniques for achieving two underlying properties — properties so fundamental to software design that they predate SOLID, predate design patterns, and show up in essentially every serious discussion of software architecture ever written. Those two properties are coupling and cohesion.

Once you can see code in terms of coupling and cohesion, the SOLID principles stop looking like five arbitrary rules to memorize and start looking like five specific, practical answers to the exact same two questions: how much does this thing know about that thing, and how well do the pieces inside this thing actually belong together?

In this lesson, you'll learn precisely what coupling and cohesion mean, why "high cohesion, low coupling" is the single most repeated goal in software design, how SRP is fundamentally a cohesion technique and Dependency Inversion is fundamentally a coupling technique, and you'll see a genuinely tightly-coupled, low-cohesion class refactored into its loosely-coupled, high-cohesion opposite.

What Is It?

The Simple Explanation

Coupling is how much one piece of code knows about — and depends on — the inner workings of another piece. Two classes are tightly coupled if a change inside one is likely to force a change inside the other. They're loosely coupled if they can change somewhat independently.

Cohesion is how closely related the things inside one class or module actually are. A class has high cohesion if everything in it genuinely serves one clear purpose. It has low cohesion if it's a grab-bag of loosely related behaviors that happen to live in the same file.

The Technical Definition

Coupling measures the degree of interdependence between modules — specifically, how much one module's design or implementation is bound up with another's. Coupling is inevitable (modules must collaborate to do anything useful) — the goal is never zero coupling, it's coupling to stable, abstract things (interfaces, contracts) rather than volatile, concrete things (another class's internal fields, a specific database library, a third-party SDK's exact shape).

Cohesion measures how strongly the responsibilities within a single module relate to one shared purpose. High cohesion means the fields and methods of a class work together toward one goal, are used together, and change together. Low cohesion means a class contains multiple unrelated clusters of behavior that just happen to share a namespace.

Why Does It Exist?

The Problem — Change Ripples Through Tightly Coupled, Low-Cohesion Systems

Tight coupling means a change to one class ripples outward into every class that depends on its concrete details — you can't touch one thing without touching several others. Low cohesion means a single class becomes a magnet for unrelated changes — every unrelated feature request finds a reason to edit the same file, and every edit risks breaking behavior that had nothing to do with the change. Put those together and you get exactly the "eighteen months in" nightmare from Lesson 235's OrderManager: everything touches everything, and nobody can predict the blast radius of a one-line change.

The Solution — "High Cohesion, Low Coupling"

This phrase is arguably the single most repeated goal in all of software design, older than SOLID and referenced by essentially every architectural discipline that followed it. It names the target directly: pull related things together (raise cohesion) and push unrelated things apart, connected only through stable abstractions (lower coupling). Everything else you'll learn in this Part — SOLID, design patterns, Clean Architecture — is, underneath, a specific technique for moving code toward this one target.

Big Picture

How It Works

Simple Example

Tight coupling in one line:

public class ReportService
{
    private readonly SqlServerConnection _connection = new("Server=prod-db;..."); //  tightly coupled to SQL Server, and even to this connection string
}

Loose coupling, same job:

public class ReportService(IReportDataSource dataSource) //  depends on an abstraction, not a database vendor
{
}

Low cohesion in one class:

public class StoreUtils //  vague name is often the first warning sign
{
    public decimal CalculateTax(decimal amount) { /* ... */ return amount * 0.08m; }
    public void SendWelcomeEmail(string email) { /* ... */ }
    public bool IsWarehouseOpen(DateTime time) { /* ... */ return true; }
}

High cohesion, same behaviors, correctly separated:

public class TaxCalculator { public decimal Calculate(decimal amount) => amount * 0.08m; }
public class WelcomeEmailSender { public void Send(string email) { /* ... */ } }
public class WarehouseScheduleChecker { public bool IsOpenAt(DateTime time) { /* ... */ return true; } }

Real-World Example — Refactoring a Tightly-Coupled, Low-Cohesion Order Class

Before — one class, tightly coupled to three concrete infrastructure pieces, with three unrelated clusters of responsibility:

public class OrderProcessor
{
    private readonly SqlConnection _db = new("Server=prod-db;...");        // tightly coupled — concrete SQL client
    private readonly SmtpClient _smtp = new("smtp.internal.local");        // tightly coupled — concrete SMTP client
    private readonly StripeClient _stripe = new("sk_live_...");            // tightly coupled — concrete Stripe SDK

    public void Process(Order order)
    {
        // Cluster 1 — payment concern
        var charge = _stripe.Charges.Create(new ChargeCreateOptions { Amount = order.TotalCents });

        // Cluster 2 — persistence concern
        var cmd = _db.CreateCommand();
        cmd.CommandText = $"INSERT INTO Orders (...) VALUES (...)";
        cmd.ExecuteNonQuery();

        // Cluster 3 — notification concern
        var mail = new MailMessage("noreply@shop.com", order.CustomerEmail, "Order Confirmed", "Thanks!");
        _smtp.Send(mail);
    }
}

The coupling problem: swap Stripe for PayPal, swap SQL Server for Postgres, or swap SMTP for a transactional email API, and every one of those swaps means editing OrderProcessor directly — because it's welded to the concrete SDK of each, not to an abstraction over what each does.

The cohesion problem: this class has three unrelated reasons to change — payment provider changes, database schema changes, email provider changes — bundled into one file. Nothing about "charging a card" is related to "formatting a SQL insert" other than that they both happen to be called from the same method.

After — loosely coupled to abstractions, each concern pulled into its own high-cohesion class:

public interface IPaymentGateway { Task ChargeAsync(Order order); }
public interface IOrderRepository { Task SaveAsync(Order order); }
public interface IOrderNotifier { Task NotifyConfirmedAsync(Order order); }

// Each implementation is high-cohesion — one job, one reason to change.
public sealed class StripePaymentGateway(StripeClient stripe) : IPaymentGateway
{
    public Task ChargeAsync(Order order) => stripe.Charges.CreateAsync(new ChargeCreateOptions { Amount = order.TotalCents });
}

public sealed class SqlOrderRepository(SqlConnection db) : IOrderRepository
{
    public Task SaveAsync(Order order) => /* INSERT ... */ Task.CompletedTask;
}

public sealed class EmailOrderNotifier(SmtpClient smtp) : IOrderNotifier
{
    public Task NotifyConfirmedAsync(Order order) =>
        Task.FromResult(smtp.Send(new MailMessage("noreply@shop.com", order.CustomerEmail, "Order Confirmed", "Thanks!")));
}

// OrderProcessor is now loosely coupled — depends on three abstractions, none of their concrete implementations —
// and high-cohesion — its one job is "orchestrate the checkout sequence," nothing more.
public sealed class OrderProcessor(IPaymentGateway payments, IOrderRepository orders, IOrderNotifier notifier)
{
    public async Task ProcessAsync(Order order)
    {
        await payments.ChargeAsync(order);
        await orders.SaveAsync(order);
        await notifier.NotifyConfirmedAsync(order);
    }
}

Swap Stripe for PayPal now, and only StripePaymentGateway changes — OrderProcessor is entirely untouched (that's low coupling in action, the same benefit Lesson 081 showed from the dependency-inversion angle). Add a discount rule, and it belongs nowhere near this class at all (that's high cohesion — OrderProcessor's one job is orchestration, not pricing).

Analogy

Under the Hood — The Design Reasoning

Common Confusion

1. "Zero coupling is the goal" — no, zero coupling means zero collaboration

Classes must talk to each other to do anything useful — a system with literally zero coupling can't function. The goal isn't eliminating coupling, it's making it point at stable abstractions instead of volatile concrete details, so the coupling that must exist is cheap to live with.

2. "Fewer classes means higher cohesion" — often the opposite

Cramming unrelated behaviors into fewer, larger classes to "simplify" the file count is exactly how low cohesion happens. More classes, each with one honest purpose, is usually the higher-cohesion outcome — the earlier StoreUtils example split into three small, focused classes.

3. "Coupling and cohesion are two names for the same idea" — they're deliberately opposite lenses

Coupling looks outward — how much does this class depend on other classes' details? Cohesion looks inward — how well do the pieces inside this one class belong together? A class can be internally cohesive and still tightly coupled to the outside world, or vice versa — they're independent measurements, which is exactly why the goal names both: "high cohesion, low coupling."

Common Mistakes

Mistake 1 — Wrapping every class in an interface, even ones with exactly one implementation that will never change

Creating ITaxCalculator, ITaxCalculatorFactory, and a registration entry for a tax rule that is genuinely fixed by law and has one, and only ever will have one, implementation — pure ceremony bought against a coupling risk that doesn't actually exist.

Introduce the abstraction when there's a real reason to expect more than one implementation, or a real testing need to substitute a fake — not reflexively, for every class.

Mistake 2 — Treating "static class full of unrelated helper methods" as harmless because it's small

public static class Helpers
{
    public static string Slugify(string input) { /* ... */ return input; }
    public static bool IsBusinessDay(DateTime date) { /* ... */ return true; }
    public static decimal RoundToCurrency(decimal value) { /* ... */ return value; }
}

It's not the size that's the problem — it's that Helpers grows without bound because there's no cohesive theme to say "no" to the next unrelated method someone adds. This is a classic low-cohesion magnet.

Group by genuine purpose: a SlugGenerator, a BusinessCalendar, a CurrencyRounder — each small, each cohesive, each with a name that tells you exactly what belongs inside it and, just as importantly, what doesn't.

Mistake 3 — Assuming an interface automatically means loose coupling

public interface IStripeChargeCreator //  named after, and shaped exactly like, one vendor's SDK
{
    Charge CreateStripeCharge(ChargeCreateOptions stripeOptions); // still Stripe's own types leaking through
}

An interface whose method signatures are shaped entirely around one vendor's SDK types is coupling in disguise — swapping Stripe for PayPal still means rewriting every consumer, because the "abstraction" never actually abstracted anything.

Design the interface around your domain's need ("charge a customer this amount"), not around one vendor's API shape — that's what makes the abstraction genuinely swappable.

When Should I Use It?

• Use coupling/cohesion as your default lens for any design review — before reaching for a named principle or pattern, ask "does this raise or lower coupling? does this raise or lower cohesion?" It's the fastest, most universal check you have.
• Invest more in loosening coupling around anything genuinely likely to change or need substituting for tests — external services, payment providers, storage.
• Don't chase zero coupling or perfect cohesion for their own sake in code that's simple, stable, and unlikely to grow — the underlying goal is manageable change, and a two-line, single-purpose script doesn't need architecture to manage change it will never undergo.

Mental Model

Key Takeaway

Check Your Understanding

You've seen the vocabulary underneath every design principle so far. Let's check it actually reframes what you already know.

You now have the vocabulary underneath every design principle in this Part — coupling and cohesion are the lens everything else gets built on.