DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports
Events Video Library
Refcards
Trend Reports

Events

View Events Video Library

Related

  • Beyond SOLID: Embracing CUPID for Modern Software Craftsmanship
  • Beyond Conversation: Mastering Context with Claude Code Skills and Agents
  • Clean Code: Interfaces in Go — Why Small Is Beautiful, Part 3
  • Unified CI/CD Interface: Strategic DevOps Acceleration

Trending

  • Zone-Free Angular: Unlocking High-Performance Change Detection With Signals and Modern Reactivity
  • Content Lakes: Harness Unstructured Data for Enterprise AI Readiness
  • Architecting Petabyte-Scale Hyperspectral Pipelines on AWS
  • Why Your QA Engineer Should Be the Most Stubborn Person on the Team

SOLID Principles by Examples: Interface Segregation

In this post, we continue our analysis of the SOLID principles of programming with the Interface Segregation Principle, or ISP.

By 
Michele Ferracin user avatar
Michele Ferracin
·
Sep. 23, 17 · Analysis
Likes (15)
Comment
Save
Tweet
Share
21.2K Views

Join the DZone community and get the full member experience.

Join For Free

This post continues the analysis of the SOLID principles and it's about the Interface Segregation Principle (ISP).

Definition

"The interface-segregation principle (ISP) states that no client should be forced to depend on methods it does not use."

The Bad Example

Here we examine an interface that violates ISP:

interface ISmartDevice
{
    void Print();

    void Fax();

    void Scan();
}

This interface states that a smart device is able to print, fax, and scan. An implementation of this interface could be an AllInPrinter class:

class AllInOnePrinter : ISmartDevice
{
    public void Print()
    {
         // Printing code.
    }

    public void Fax()
    {
         // Beep booop biiiiip.
    }

    public void Scan()
    {
         // Scanning code.
    }
}

Simple, isn't it? Right. Now suppose we need to handle a dumb device (EconomicPrinter class) that can only print. We're forced to implement the Whole interface, for example:

class EconomicPrinter : ISmartDevice
{
    public void Print()
    {
        //Yes I can print.
    }

    public void Fax()
    {
        throw new NotSupportedException();
    }

    public void Scan()
    {
        throw new NotSupportedException();
    }
}

This is not very good.

The Good Example

Here we apply the ISP and we separate the single ISmartDevice interface into three smaller interfaces: IPrinter, IFax, and IScanner.

interface IPrinter{
    void Print();
}

interface IFax{
    void Fax();
}

interface IScanner{
    void Scan();
}

This way, it's easier to implement classes that do not need to handle all the original functionalities of the ISmartDevice, interface like our EconomicPrinter. Our code is more decoupled and easier to maintain. Let's re-implement our EconomicPrinter with this architecture:

class EconomicPrinter : IPrinter
{
    public void Print()
    {
         // Printing code.
    }

}

The original AllInOnePrinter now looks like this:

class AllInOnePrinter : IPrinter, IFax, IScanner
{
    public void Print()
    {
         // Printing code.
    }

    public void Fax()
    {
         // Beep booop biiiiip.
    }

    public void Scan()
    {
         // Scanning code.
    }

}

TL;DR

The ISP guides us to create many small interfaces with coherent functionalities instead of a few big interfaces with lots of different methods. When we apply the ISP, class and their dependencies communicate using focused interfaces, minimizing dependencies. Smaller interfaces are easier to implement, improving flexibility and the possibility of reuse.

Interface (computing)

Published at DZone with permission of Michele Ferracin. See the original article here.

Opinions expressed by DZone contributors are their own.

Related

  • Beyond SOLID: Embracing CUPID for Modern Software Craftsmanship
  • Beyond Conversation: Mastering Context with Claude Code Skills and Agents
  • Clean Code: Interfaces in Go — Why Small Is Beautiful, Part 3
  • Unified CI/CD Interface: Strategic DevOps Acceleration

Partner Resources

×

Comments

The likes didn't load as expected. Please refresh the page and try again.

  • RSS
  • X
  • Facebook

ABOUT US

  • About DZone
  • Support and feedback
  • Community research

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Core Program
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 215
  • Nashville, TN 37211
  • [email protected]

Let's be friends:

  • RSS
  • X
  • Facebook