Interface segregation principle is the idea that clients should not be forced to depend on interfaces they do not use. It's one of the SOLID principles that Uncle Bob won't shut up about, even though most of us just want to ship some damn code.

How to use it in a sentence

• "I know the PR looks huge, but I swear I'm following the interface segregation principle! I mean, just because the new Payments interface has 27 methods doesn't mean every client needs to implement all of them, right?"

• "Yo, I heard you like the interface segregation principle. So I put an interface in your interface so you can segregate while you segregate."

If you actually want to learn more...

A few additional resources related to the interface segregation principle and API design:

• Inversion of Control - A common phenomenon when extending frameworks that is often seen as a defining characteristic. Understanding this can help when applying the interface segregation principle.

• Role Interface - Defining interfaces by looking at specific interactions between suppliers and consumers, rather than having a single monolithic interface. This approach aligns well with the goals of the interface segregation principle.

• Published Interface - The distinction between published interfaces used outside a codebase vs just marking something as public. Considering this can help guide how you apply the interface segregation principle for internal vs external APIs.

Note: the Developer Dictionary is in Beta. Please direct feedback to skye@statsig.com.