728x90
📚 Chapter 2.1.4. ISP (Interface Segregation Principle) – 인터페이스 분리 원칙
✅ ISP란?
"하나의 클라이언트가 자신이 사용하지 않는 메서드에 의존하지 않게 해야 한다."
쉽게 말하면,
- "인터페이스는 작게 작게 쪼개라!"
- "필요한 기능만 가진 인터페이스만 제공해라!"
📚 왜 ISP가 중요한가?
| 문제 상황 | 결과 |
|---|---|
| 거대한 인터페이스 | 필요 없는 메서드도 강제로 구현해야 함 |
| 코드 복잡성 증가 | 무쓸모 코드들이 시스템을 오염시킴 |
| 유지보수 난이도 상승 | 하나 바꾸면 연쇄 수정 지옥 |
✅ ISP를 지키면 →
- 필요한 기능만 깔끔하게 다루고,
- 코드 수정 범위 최소화된다!
🛠️ 기본 나쁜 예제: ISP 위반
덩치 큰 인터페이스
public interface IWorker
{
void Work();
void Eat();
}
서로 다른 요구를 가진 클래스
public class HumanWorker : IWorker
{
public void Work() => Console.WriteLine("일한다!");
public void Eat() => Console.WriteLine("식사한다!");
}
public class RobotWorker : IWorker
{
public void Work() => Console.WriteLine("로봇이 일한다!");
public void Eat()
{
throw new NotImplementedException("로봇은 밥 안 먹는다!");
}
}
❌ 문제점
- 로봇은 Eat() 필요 없는데도
- 강제로 메서드를 구현해야 함! (심지어 예외 던져야 함 ㅋㅋ)
👉 인터페이스가 너무 커서 억지 구현 발생 → ISP 위반
🛠️ 좋은 예제: ISP 적용
인터페이스 분리!
public interface IWorkable
{
void Work();
}
public interface IFeedable
{
void Eat();
}
각 클래스는 필요한 것만 구현
public class HumanWorker : IWorkable, IFeedable
{
public void Work() => Console.WriteLine("일한다!");
public void Eat() => Console.WriteLine("식사한다!");
}
public class RobotWorker : IWorkable
{
public void Work() => Console.WriteLine("로봇이 일한다!");
}
✅ 이제 필요한 것만 선택해서 구현할 수 있다!
"억지 구현" 따위 필요 없음!
📚 실무 스타일 예시: 파일 입출력
| 상황 | 잘못된 설계 |
|---|---|
| 파일 저장, 로드, 삭제 기능을 한 인터페이스에 몰빵 | 필요 없는 메서드까지 강제로 구현해야 함 |
ISP 적용하면?
- ISaveable, ILoadable, IDeletable 기능별 인터페이스 분리해서
- 필요한 것만 골라 쓴다!
✨ ISP 심화 – 실전 설계 꿀팁
| 상황 | 해결법 |
|---|---|
| 인터페이스 메서드 5개 이상 | 쪼개는 거 검토해라 |
| 일부 구현체가 NotImplementedException 던진다 | 100% 인터페이스 분리 부족하다 |
| 인터페이스 메서드명에 "And" 들어간다 | 기능 분리 신호다! (SaveAndLoad ❌) |
🎯 ISP를 지키면 생기는 실무 장점
| 항목 | 효과 |
|---|---|
| 인터페이스 명확성 | 필요한 기능만 명확하게 설계 |
| 유지보수 쉬움 | 수정 범위 최소화 |
| 재사용성 향상 | 작은 단위 인터페이스 재활용 가능 |
| 테스트 용이 | 테스트 더 깔끔하고 빠름 |
✅ ISP 요약
| 항목 | 설명 |
|---|---|
| 목표 | 클라이언트가 필요 없는 메서드에 의존하지 않게 한다 |
| 신호 | 인터페이스 거대해지면 분리 고려 |
| 해결책 | 기능별로 인터페이스 쪼개기 |
728x90