Interface Segregation

The idea and when to recognize it

Clients should depend only on capabilities they actually use. A focused contract avoids forcing implementations to fake or reject unrelated operations.

• Requirement: A print job should work with a basic printer even when the device cannot scan.
• Change to anticipate: Use print-only devices without requiring a scanner method or silently skipping the print job.
• Design goal: Expose printing and scanning as separate capabilities and invoke only the requested supported operation.

Start with the concrete problem

A print job should work with a basic printer even when the device cannot scan.

Use print-only devices without requiring a scanner method or silently skipping the print job.

Responsibilities and contracts

Expose printing and scanning as separate capabilities and invoke only the requested supported operation.

• Printer: Supports printing. Public operations: print(document)
• Scanner: Supports scanning. Public operations: scan()
• PrintClient: Uses only printing. Public operations: run(printer)

Read the design

Select a participant to inspect its responsibility and public operations. Follow the labeled relationships; an arrow indicates direction, while the legend distinguishes ownership, substitution, and temporary use.

Preparing the design walkthrough…

Follow the interaction

Choose a supplied workload and compare the direct and revised implementations. Step through the same operation in both languages. Object values are recorded after each highlighted statement; previous steps remain unchanged.

Preparing the design walkthrough…

Implementation and expected output

Read the complete example alongside its input and expected output. The implementation selector changes the displayed program; the language selector preserves your current scenario and playback position.

Preparing the design walkthrough…

Try the idea in another setting

A read-only repository should not need dummy create and delete methods to serve a reporting client.

• Name the new client contract before adapting the example.
• Identify which state belongs to each object and who controls its lifetime.
• Write one normal case and one boundary case before extending the design.

Tradeoffs and interview takeaways

Too many tiny interfaces can become difficult to navigate. Split by client needs and meaningful capabilities rather than making one interface per incidental line.

Common mistake: Requiring scan support before printing rejects a device that already fulfills the print contract.

• Explain the choice: Expose printing and scanning as separate capabilities and invoke only the requested supported operation.
• Challenge your choice: Too many tiny interfaces can become difficult to navigate. Split by client needs and meaningful capabilities rather than making one interface per incidental line.
• Describe a requirement that would make the simpler implementation sufficient.

Design challenge and knowledge check

Preparing the design walkthrough…