ISP vs SRP — interface segregation vs single responsibility

Direct Answer

SRP asks whether a class or module has one primary reason to change. ISP asks whether a client depends on a contract containing operations it does not use. One concerns responsibility and change ownership; the other concerns the shape of client-facing capabilities. A large service and a fat interface often appear together, but either violation can exist alone.

Code Example

// ISP: the report client sees only the capability it uses.
interface InvoiceReader {
    Invoice find(long id);
}

// SRP: formatting and delivery change for different reasons.
final class InvoiceFormatter {
    String format(Invoice invoice) { return invoice.toString(); }
}

final class InvoiceMailer {
    void send(String body, String address) { /* SMTP adapter */ }
}

The focused reader contract addresses ISP. Separating formatting from delivery addresses SRP. Neither improvement automatically proves the other.

Common Mistakes & Pitfalls

• Calling SRP the class version of ISP: responsibility and client dependency are different questions.
• Assuming small interfaces prove SRP: one implementation can still own unrelated policies.
• Assuming a cohesive class has a good client API: a narrow client may still receive too many operations.
• Applying both mechanically: use actual change reasons and usage patterns.