인터페이스 분리 원칙
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
1. 개요
인터페이스 분리 원칙(ISP)은 객체 지향 설계 원칙 중 하나로, 클래스가 사용하지 않는 메서드에 의존하지 않도록 인터페이스를 분리해야 한다는 원칙이다. 이 원칙은 로버트 C. 마틴이 제록스 프린터 시스템 개발 과정에서 처음 사용하고 공식화했다. ISP는 '뚱뚱한' 인터페이스로 인해 발생하는 문제점을 해결하기 위해, 클라이언트가 필요한 메서드만 포함하는 작은 인터페이스들로 분리하여 시스템의 유연성과 유지보수성을 향상시키는 데 기여한다. ATM 트랜잭션 예시와 같이, ISP를 위반하는 경우 불필요한 의존성이 발생하여 변경의 어려움과 잠재적인 오류를 야기할 수 있다.
더 읽어볼만한 페이지
- 프로그래밍 원칙 - 블랙박스
블랙 박스는 자극 입력과 출력 반응의 관점에서 시스템을 추상화하여 외부적으로 관찰하는 이론으로, 전자 회로 이론, 사이버네틱스, 시스템 이론 등 다양한 분야에서 활용되며 예측 모델 구축 및 유효성 검증, 그리고 항공기 비행 기록 장치나 함수 교육 도구 등 실생활에도 응용된다. - 프로그래밍 원칙 - 정보 은닉
정보 은닉은 소프트웨어 설계에서 모듈 내부 구현을 숨기고 정의된 인터페이스를 통해서만 상호 작용하도록 하여 모듈 독립성을 높이고 시스템 복잡성을 관리하는 데 중요한 기법으로, 객체 지향 프로그래밍의 캡슐화와 관련된다. - 소프트웨어 설계 - 구조적 분석
구조적 분석은 1960년대에서 1980년대 소프트웨어 개발의 복잡성을 해결하기 위해 개발된 기법으로, 다이어그램과 데이터 사전을 활용하여 시스템을 분석하고 설계했으며, 객체 지향 프로그래밍의 등장으로 활용도가 감소했다. - 소프트웨어 설계 - 지속적 배포
지속적 배포(CD)는 소프트웨어 릴리스 프로세스를 자동화하는 접근 방식이며, 배포 파이프라인을 통해 구현되고 시장 출시 시간 단축, 제품 품질 향상 등의 이점을 제공하지만 테스트 자동화 부족 등의 과제도 존재한다. - 객체 지향 프로그래밍 - Is-a
Is-a 관계는 객체 지향 프로그래밍에서 한 유형이 다른 유형의 하위 유형임을 나타내는 관계로, 상속, 서브타이핑, 리스코프 치환 원칙과 관련되며, C++, Python, Java 등에서 표현된다. - 객체 지향 프로그래밍 - 객체 (컴퓨터 과학)
객체는 객체 지향 프로그래밍에서 데이터와 조작을 묶어 메시지를 수신하고, 프로그램의 개념을 표현하며 가시성과 재사용성을 높이는 실체이다.
| 인터페이스 분리 원칙 | |
|---|---|
| 개요 | |
| 분야 | 소프트웨어 공학 |
| 하위 분야 | 객체 지향 프로그래밍, 디자인 패턴 |
| 문제 | 클래스가 사용하지 않는 메서드에 의존하게 됨 |
| 해결책 | 큰 인터페이스를 더 작고 특화된 인터페이스로 분할 |
| 원칙 | 클라이언트는 자신이 사용하지 않는 메서드에 의존하도록 강요받아서는 안 된다. |
| 상세 내용 | |
| 목표 | 큰 인터페이스를 작은 인터페이스로 분리하여 클라이언트가 실제로 사용하는 메서드만 구현하도록 함 |
| 장점 | 클라이언트 코드의 불필요한 의존성 제거 시스템의 결합도 감소 및 유지보수성 향상 SRP(단일 책임 원칙) 및 LSP(리스코프 치환 원칙) 준수 용이 |
| 예시 | 프린터 인터페이스를 스캐너, 복사기 인터페이스 등으로 분리 |
| SOLID 원칙 | |
| 구성 요소 | 단일 책임 원칙 개방-폐쇄 원칙 리스코프 치환 원칙 인터페이스 분리 원칙 의존관계 역전 원칙 |
2. 객체 지향 설계에서의 중요성
객체 지향 설계에서 인터페이스는 시스템 결합도를 낮추는 추상화 계층을 제공한다.[1] 이를 통해 한 부분의 변경이 다른 여러 부분에 영향을 미치는 것을 최소화하여 유지보수성을 향상시킨다.
2. 1. 인터페이스와 추상 클래스
객체 지향 설계에서 인터페이스는 코드를 단순화하고 의존성과의 결합을 방지하는 추상화 계층을 제공한다. 시스템은 여러 수준에서 매우 결합되어 한 곳에서 변경을 하려면 여러 곳에서 추가적인 변경이 필요하게 될 수 있다.[1] 인터페이스 또는 추상 클래스를 사용하면 이러한 부작용을 방지하고 시스템에 유연성을 확보할 수 있다.3. 원리
로버트 C. 마틴[5]은 제록스의 컨설턴트로 일하면서 인터페이스 분리 원칙을 처음 사용하고 공식화했다. 제록스는 스테이플링 및 팩스와 같은 다양한 작업을 수행할 수 있는 새로운 프린터 시스템을 만들었는데, 이 시스템의 소프트웨어 개발 과정에서 수정 작업이 어려워지는 문제가 발생했다. 이에 마틴은 인터페이스 분리 원칙을 제안하여 이 문제를 해결했다.
3. 1. 제록스 프린터 시스템 문제
로버트 C. 마틴[5]은 제록스의 컨설턴트로 일하면서 인터페이스 분리 원칙을 처음 사용하고 공식화했다. 제록스는 스테이플링 및 팩스와 같은 다양한 작업을 수행할 수 있는 새로운 프린터 시스템을 만들었다. 이 시스템의 소프트웨어는 처음부터 만들어졌다. 소프트웨어가 커지면서 수정 작업이 점점 더 어려워졌고, 가장 작은 변경이라도 한 시간의 재배포 주기가 필요해 개발이 거의 불가능하게 되었다.이러한 설계 문제는 단일 'Job' 클래스가 거의 모든 작업에 사용되었다는 점이다. 인쇄 작업이나 스테이플링 작업을 수행해야 할 때마다 Job 클래스를 호출했다. 그 결과 다양한 클라이언트에 특정한 수많은 메서드를 가진 '뚱뚱한' 클래스가 되었다. 이 설계로 인해 스테이플 작업은 인쇄 작업에 대한 모든 메서드를 알게 되었지만, 사용할 필요는 없었다.
3. 2. 해결책: 인터페이스 분리
로버트 C. 마틴[5]은 인터페이스 분리 원칙을 적용하여, 의존성 역전 원칙을 사용해 Job 클래스와 클라이언트 간 인터페이스 계층을 추가했다. 하나의 큰 Job 클래스를 사용하는 대신, 각 작업 유형에 맞는 개별 인터페이스(Staple Job, Print Job 등)를 생성하여 클라이언트가 필요한 메서드만 사용하도록 했다. 이 인터페이스들은 모두 Job 클래스에 의해 구현되었다.4. 위반 사례
인터페이스 분리 원칙(ISP)의 위반 사례는 로버트 C. 마틴이 제시한 'ATM 트랜잭션 예시'에서 찾아볼 수 있다.[6][1] 이 예시는 ATM 사용자 인터페이스가 입금, 출금 등 모든 요청을 처리하는 방식이 어떻게 더 구체적인 인터페이스로 분리될 수 있는지 보여준다.
4. 1. ATM 트랜잭션 예시
로버트 C. 마틴이 직접 작성한 기사[6]와 애자일 소프트웨어 개발: 원칙, 패턴 및 실천[1]에서는 인터페이스 분리 원칙을 위반하는 전형적인 사례로 'ATM 트랜잭션 예시'를 제시한다. 이 예시는 입금, 출금 등 모든 요청을 처리하는 ATM 사용자 인터페이스가 어떻게 더 구체적인 인터페이스(예: 입금 인터페이스, 출금 인터페이스)로 분리되어야 하는지를 보여준다.참조
[1]
서적
Agile Software Development: Principles, Patterns, and Practices
Pearson Education
2002
[2]
웹사이트
Role Interface
http://martinfowler.[...]
[3]
웹사이트
David Hayden, ''Interface-Segregation Principle (ISP) - Principles of Object-Oriented Class Design''
https://web.archive.[...]
2009-11-07
[4]
간행물
"Principles for Microservice Design: Think IDEALS, Rather than SOLID"
https://www.infoq.co[...]
The InfoQ eMag Issue #91
2021-02
[5]
웹사이트
This principle was first defined by Robert C. Martin
https://www.baeldung[...]
[6]
간행물
The Interface Segregation Principle
https://docs.google.[...]
C++ Report
1996-06
[7]
서적
Agile Software Development: Principles, Patterns and Practices
Pearson Education
2002
[8]
웹사이트
Role Interface
http://martinfowler.[...]
[9]
웹인용
David Hayden, ''Interface-Segregation Principle (ISP) - Principles of Object-Oriented Class Design''
https://web.archive.[...]
2015-04-07
본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.
문의하기 : help@durumis.com