Back to results for “Interfaces & Abstract Classes”
C# › Interfaces & Abstract Classes

How does interface segregation (the 'I' in SOLID) guide splitting a large, monolithic interface into several smaller, more focused ones?

Advanced

Answer

The Interface Segregation Principle states that clients shouldn't be forced to depend on methods they don't actually use — a large interface with many unrelated members should be SPLIT into several smaller, cohesive interfaces, letting each implementing class (and each consumer) depend only on the specific capabilities it genuinely needs.
// Before: monolithic, forces unrelated dependencies
public interface IWorker { void Work(); void Eat(); void Sleep(); }

// After: segregated into focused interfaces
public interface IWorkable { void Work(); }
public interface IFeedable { void Eat(); }
public class Robot : IWorkable { public void Work() { } } // doesn't need Eat/Sleep at all
Real-world example Refactoring a bloated 'god interface' that forces every implementer to stub out methods they don't actually need.

Common follow-ups: How does a segregated interface design specifically improve testability compared to one large interface?