Interface Segregation Principle

C#: the screen asks for more than it uses

These examples target .NET 8 and use System and System.Collections.Generic. Add their using directives at file level. Class and interface declarations belong at file level; calling statements belong inside a method. Treat the original and refactored versions as separate programs.

public interface IEmailDirectory
{
    string EmailFor(string name);
    void SetEmail(string name, string email);
}

public sealed class MemoryDirectory : IEmailDirectory
{
    private readonly Dictionary<string, string> emails = new Dictionary<string, string>();

    public string EmailFor(string name)
    {
        return emails[name];
    }

    public void SetEmail(string name, string email)
    {
        emails[name] = email;
    }
}

public sealed class DirectoryPage
{
    private readonly IEmailDirectory directory;

    public DirectoryPage(IEmailDirectory directory)
    {
        this.directory = directory;
    }

    public string Show(string name)
    {
        string email = directory.EmailFor(name);
        return $"{name}: {email}";
    }
}

DirectoryPage.Show uses EmailFor and never uses SetEmail. Nevertheless, its constructor requires the entire IEmailDirectory interface. Any object supplied through that interface must provide both methods.

MemoryDirectory directory = new MemoryDirectory();
directory.SetEmail("Mira", "mira@example.test");
DirectoryPage page = new DirectoryPage(directory);
Console.WriteLine(page.Show("Mira"));
// Mira: mira@example.test

The code works. The problem appears when we want to supply a directory that can only answer lookups—for example, a fixed snapshot exported from another system. It has what Show needs, but not everything its constructor demands.

Python: the annotation asks for more than the method uses

A Python protocol describes the methods an object is expected to provide. Type-checking tools can use that description; ordinary Python execution does not enforce it merely because an annotation exists. The ... bodies below declare protocol methods, not missing implementations in the directory itself. 3

from typing import Protocol


class EmailDirectory(Protocol):
    def email_for(self, name: str) -> str:
        ...

    def set_email(self, name: str, email: str) -> None:
        ...


class MemoryDirectory:
    def __init__(self):
        self.emails: dict[str, str] = {}

    def email_for(self, name: str) -> str:
        return self.emails[name]

    def set_email(self, name: str, email: str) -> None:
        self.emails[name] = email


class DirectoryPage:
    def __init__(self, directory: EmailDirectory):
        self.directory = directory

    def show(self, name: str) -> str:
        email = self.directory.email_for(name)
        return f"{name}: {email}"

DirectoryPage.show calls only email_for. Its annotation nevertheless says that a supplied object should also provide set_email. MemoryDirectory happens to provide both:

directory = MemoryDirectory()
directory.set_email("Mira", "mira@example.test")
page = DirectoryPage(directory)
print(page.show("Mira"))
# Mira: mira@example.test

A lookup-only object would already work at runtime because show never calls the editing method. But it would not satisfy the declared EmailDirectory protocol. The repair below makes the declared requirement match the method’s actual need; it does not unlock a previously impossible Python call.

C#: two interfaces, one implementation

public interface IEmailLookup
{
    string EmailFor(string name);
}

public interface IEmailEditor
{
    void SetEmail(string name, string email);
}

public sealed class MemoryDirectory : IEmailLookup, IEmailEditor
{
    private readonly Dictionary<string, string> emails = new Dictionary<string, string>();

    public string EmailFor(string name)
    {
        return emails[name];
    }

    public void SetEmail(string name, string email)
    {
        emails[name] = email;
    }
}

public sealed class DirectoryPage
{
    private readonly IEmailLookup directory;

    public DirectoryPage(IEmailLookup directory)
    {
        this.directory = directory;
    }

    public string Show(string name)
    {
        string email = directory.EmailFor(name);
        return $"{name}: {email}";
    }
}

DirectoryPage now requests IEmailLookup. The lookup and formatting statements inside Show are unchanged. MemoryDirectory still stores and updates addresses exactly as before; its declaration says it implements both interfaces. C# allows a class to implement multiple interfaces. 2

MemoryDirectory directory = new MemoryDirectory();
IEmailEditor editor = directory;
editor.SetEmail("Mira", "mira@example.test");

DirectoryPage page = new DirectoryPage(directory);
Console.WriteLine(page.Show("Mira"));
// Mira: mira@example.test

The editing reference and the page use the same directory object. They ask for different operations from it.

Supply a lookup-only snapshot

public sealed class SnapshotDirectory : IEmailLookup
{
    private readonly Dictionary<string, string> emails;

    public SnapshotDirectory(Dictionary<string, string> initialEmails)
    {
        emails = new Dictionary<string, string>(initialEmails);
    }

    public string EmailFor(string name)
    {
        return emails[name];
    }
}

SnapshotDirectory copies the supplied entries. It exposes no editing method, and later changes to the original dictionary do not change that copy.

Dictionary<string, string> exported = new Dictionary<string, string>();
exported["Mira"] = "mira@example.test";

SnapshotDirectory snapshot = new SnapshotDirectory(exported);
DirectoryPage page = new DirectoryPage(snapshot);
Console.WriteLine(page.Show("Mira"));
// Mira: mira@example.test

The page accepts this class because its interface now states only what it needs. No dummy SetEmail method is necessary.

Python: describe the two capabilities separately

from typing import Protocol


class EmailLookup(Protocol):
    def email_for(self, name: str) -> str:
        ...


class EmailEditor(Protocol):
    def set_email(self, name: str, email: str) -> None:
        ...


class MemoryDirectory:
    def __init__(self):
        self.emails: dict[str, str] = {}

    def email_for(self, name: str) -> str:
        return self.emails[name]

    def set_email(self, name: str, email: str) -> None:
        self.emails[name] = email


class DirectoryPage:
    def __init__(self, directory: EmailLookup):
        self.directory = directory

    def show(self, name: str) -> str:
        email = self.directory.email_for(name)
        return f"{name}: {email}"

DirectoryPage now requests EmailLookup. The lookup and formatting statements inside show are unchanged. MemoryDirectory still stores and updates addresses exactly as before.

It satisfies both protocols by providing their methods. It does not need to inherit from the protocol classes for structural type checking. 3

directory = MemoryDirectory()
editor: EmailEditor = directory
editor.set_email("Mira", "mira@example.test")

page = DirectoryPage(directory)
print(page.show("Mira"))
# Mira: mira@example.test

Supply a lookup-only snapshot

class SnapshotDirectory:
    def __init__(self, initial_emails: dict[str, str]):
        self._emails = dict(initial_emails)

    def email_for(self, name: str) -> str:
        return self._emails[name]

SnapshotDirectory copies the supplied entries and provides only the lookup method. Later changes to the original dictionary do not change that copy. The underscore marks _emails as internal by convention; Python does not make it inaccessible.

exported = {"Mira": "mira@example.test"}
snapshot = SnapshotDirectory(exported)
page = DirectoryPage(snapshot)
print(page.show("Mira"))
# Mira: mira@example.test

The snapshot now satisfies the page’s declared requirement, as well as its runtime needs. It does not need a dummy set_email method.