Interface Segregation Principle – Clean Mobile Architecture by Petros Efthymiou

The Interface Segregation Principle (ISP) is a core component of clean architecture, guiding how to design interfaces that support specific client needs without unnecessary dependencies. By adhering to ISP, developers create interfaces that are lean and focused, fostering modular, adaptable, and maintainable code.

---

What is the Interface Segregation Principle?

Definition: The Interface Segregation Principle states that a client should not be forced to implement interfaces it does not use. This principle encourages designing interfaces that serve specific client needs, keeping them focused and free from unnecessary methods.

ISP is particularly useful in mobile applications where components often have unique functionality requirements. Creating smaller, specific interfaces helps keep code clean and prevents coupling between unrelated components, leading to better code reuse and flexibility.

---

Problem Scenario

Imagine developing a media app with multiple media types, such as Audio and Video, each requiring specific actions. If you created a single Media interface with methods for all media-related operations (e.g., play, pause, record), some classes, like Audio, might implement methods it doesn’t need, such as startVideo() and stopVideo(). This setup clutters the codebase and introduces unwanted dependencies.

---

Applying the Interface Segregation Principle

Let’s see how the Interface Segregation Principle can help structure interfaces for media components, using a Clean Mobile Architecture approach.

Step 1: Define Granular Interfaces

Begin by creating smaller, purpose-specific interfaces instead of a single, all-encompassing one.

public interface Playable {
    void play();
    void pause();
}

public interface Recordable {
    void record();
    void stopRecording();
}

With these interfaces, only classes that require specific behaviors will implement the corresponding interfaces. For instance, Audio might be both Playable and Recordable, while Video might only be Playable.

Step 2: Create Classes Implementing Specific Interfaces

Now, implement these interfaces in classes that require their functionality, without redundant methods.

public class Audio implements Playable, Recordable {
    @Override
    public void play() {
        System.out.println("Playing audio...");
    }

    @Override
    public void pause() {
        System.out.println("Pausing audio...");
    }

    @Override
    public void record() {
        System.out.println("Recording audio...");
    }

    @Override
    public void stopRecording() {
        System.out.println("Stopping audio recording...");
    }
}

public class Video implements Playable {
    @Override
    public void play() {
        System.out.println("Playing video...");
    }

    @Override
    public void pause() {
        System.out.println("Pausing video...");
    }
}

Step 3: Implement Dependency Injection to Promote Flexibility

Using dependency injection allows for flexible assignments of specific interfaces, adhering to ISP. For instance, the MediaController can now work with any Playable instance, without enforcing unnecessary dependencies.

public class MediaController {
    private Playable media;

    public MediaController(Playable media) {
        this.media = media;
    }

    public void start() {
        media.play();
    }

    public void stop() {
        media.pause();
    }
}

Step 4: Client Code

In client code, MediaController can interact with any Playable media type, such as Audio or Video, demonstrating the interface's specificity and flexibility.

public class MediaTest {
    public static void main(String[] args) {
        Playable audio = new Audio();
        MediaController audioController = new MediaController(audio);
        audioController.start();
        audioController.stop();

        Playable video = new Video();
        MediaController videoController = new MediaController(video);
        videoController.start();
        videoController.stop();
    }
}

Output:

Playing audio...
Pausing audio...
Playing video...
Pausing video...

Since MediaController relies only on the Playable interface, it works seamlessly with both Audio and Video, adhering to ISP without unnecessary dependencies.

---

Benefits of the Interface Segregation Principle

• Focused Code: Each interface serves a specific purpose, making code easier to understand and maintain.

• Reduced Coupling: Classes are not forced to depend on methods they don’t use, leading to fewer dependencies.

• Enhanced Reusability: Smaller, purpose-built interfaces are more reusable across different parts of the codebase.

• Improved Flexibility: New features can be added with minimal changes to existing code, adhering to clean architecture’s principles.

---

Bullet Points

• The Interface Segregation Principle encourages creating interfaces tailored to specific client needs.

• ISP reduces code clutter and dependency, making components easier to test, extend, and maintain.

• This principle is especially useful in modular systems, such as mobile apps, where each component often serves a unique purpose.

• Small, purpose-driven interfaces lead to more predictable and manageable codebases, fostering clean architecture.

---

Conclusion

The Interface Segregation Principle is a powerful design principle that keeps your codebase clean, modular, and flexible. By adhering to ISP, you avoid unnecessary dependencies and ensure that each component only knows what it needs to know, enhancing code readability and maintainability. This focused approach enables mobile applications to be easily adaptable to new requirements, supporting clean mobile architecture at its core.

---