Interface segregation I

01 / MEET THE PRINCIPLE

What is Interface segregation?

Give clients the interfaces they need, without forcing them to depend on unrelated operations.

First understand the idea. Then explore why it helps, before bringing it to life in the harbour.

WHERE THE IDEA BEGAN

A little history.

Interface segregation is one of the object-oriented design principles described in Robert C. Martin’s 2000 Design Principles and Design Patterns paper. It focuses on keeping client dependencies narrow.

02 / WHY IT MATTERS

Why use it?

Where it helps

Useful in broad service APIs, device contracts and applications where different screens or clients use different capabilities.

Why use it?

Each client depends on the operations that make sense for its task. A change to scanning need not force printing-only clients to understand the scanning API.

What if you ignore it?

Implementations may add meaningless methods or throw NotSupportedException. Clients become coupled to capabilities they never needed.

KNOW THE TRADE-OFF

Useful, not absolute.

Small means focused on a client’s needs, not necessarily one method per interface. Too many fragmented contracts can make navigation and implementation harder.

Next, step into the story and see this problem through a familiar situation.

03 / ONCE UPON A CHANGE

Hire the tool.
Not the whole shed.

The tool shop’s universal machine contract demands printing, scanning and faxing. A small label printer must claim it can do all three, while the shipping desk only ever asks it to print. That oversized promise serves neither of them.

Offer clearly labelled tools. The shipping desk asks for a printer; the archive asks for a scanner. A multifunction machine can provide both without making every customer depend on both.

Turn to “Try it” to change the design and see what happens.

04 / PULL THE PAPER TAB

What happens
when things change?

IMachine requires Print, Scan and Fax from the label printer.

IMachine requires Print, Scan and Fax from the label printer.

Choose a scenario, then try the change.

An illustrative model, not a benchmark or a claim that every design change causes a bug.

05 / FROM STORY TO CODE

Spot the dependency.

Give clients the interfaces they need, without forcing them to depend on unrelated operations.

Before

interface IMachine
{
    void Print();
    void Scan();
    void Fax();
}
// A label printer cannot honestly provide all three.

A MORE FOCUSED DESIGN

After

interface IPrinter { void Print(); }
interface IScanner { void Scan(); }

class ShippingDesk
{
    private readonly IPrinter printer;
    public ShippingDesk(IPrinter printer)
        { this.printer = printer; }
}

Illustrative C# sketches. Supporting types and method bodies are omitted; these snippets are not executed in the page.

06 / MAKE IT STICK

Take the idea
with you.

Give clients the interfaces they need, without forcing them to depend on unrelated operations.

Try the question opposite, then continue to the next principle.