The Interface Segregation Principle favors small, consumer-specific interfaces over broad dependencies. Keep only the functions, names, and parameters each consumer needs, often behind an adapter. section 4.8.4
A broad dependency can make application code and tests follow unnecessary complexity. An adapter narrows that dependency to a simpler contract, so changes to the real interface usually stay inside one adapter module. section 4.8.4 section 6.2.2
A focused network adapter
Instead of exposing every operation from a fetching library, expose one application-oriented function: fetchUrlText(url), returning { ok, text }. The website verifier depends on this small contract, while the adapter alone imports and translates the underlying fetching library. section 6.2.2
Testing through the smaller contract
A test can replace the network adapter with a fake returning good or bad content. The verifier then exercises its own behavior without contacting the network or reproducing the fetch library's full interface. section 6.2.2
Figure 6.7 Wrapping the node-fetch module with our own network-adapter module helps us expose only the functionality our application needs, expressed in the language most suitable for the problem at hand.
Use the adapter diagram to see how a complex fetching dependency is wrapped and reduced to application-specific functionality. section 6.2.2
Apply the principle by:
- Identifying the operations a consumer actually needs. section 4.8.4
- Creating an adapter with fewer functions, clearer names, and fewer parameters. section 4.8.4
- Injecting or mocking the adapter so tests control the dependency. section 6.2.2
