객체지향 설계 원칙 5-5 ISP (Interface Segregation Principle)

객체지향 설계 원칙 5-5 ISP (Interface Segregation Principle) 인터페이스 격리 원칙

객체지향의 설계원칙 중 마지막인 인터페이스 분리의 법칙이다.
객체는 자신의 기능을 다른 객체가 사용하기 위한 대표적인 방법은 인터페이스를 노출하는 것이다. 객체가 노출한 인터페이스를 통해 객체간의 커뮤니케이션이 일어난다. 이 인터페이스 분리의 법칙은 인터페이스를 노출하는 방법에 관한 이야기이다. ISP 를 한마디로 표현하면 다음과 같다.

"클라이언트가 사용하지 않는 인터페이스 때문에 클라이언트가 영향을 받아서는 안된다."

 여러개의 클라이언트가 사용하는 모든 인터페이스를 모아 두지 말고 하나의 클라이언트가 사용하는 하나의 인터페이스 집합을 만들어 사용해야 한다. 이것은 단일 책임의 원칙과 유사하게 해석될수도 있다. 하나가 인터페이스가 변경된다면 하나의 객체만 변경되어야 한다는 말이다.

마침 이에관한 좋은 예제가 하나 있다. 내가 요즘 서버를 개발중에 있다. 그것도 두개의 서버를 동시에 개발한다. 하나의 게임에서 사용할 서버이고 편의상 A 서버 B 서버로 칭하겠다.  그런데 클라이언트 쪽에서는 이 서버에 통신하는 부분을 개발할 시간이 없단다. ㅡㅡ 그래서 이 A, B 서버와 통신하는 클라이언트 Stub 을 라이브러리 형태로 같이 개발해 달라고 한다. 귀찮게 시리 ㅡㅡ

그래서 클라이언트 라이브러리를 개발하기 위해 다은과 같은 구성을 생각했다.

[그림 1]

위 그림을 보면 "A 클라이언트"는 A_prtocol 을 사용하여 "A 서버" 와 통신을 하고 B 클라이언트는 B_protocol 을 사용하여 통신할 것이다.  그러면 여기서 어떤 문제가 발생하겠는가 ?
먼저 "A 클라이언트"는 B_protocol() 을 사용하지 않는다. "A 클라이언트" 에서 알고 싶지도 알아야 할 필요도 없는 정보이다. 그런데 만일 B_protocol() 이 수정되었거나 또는 "B 클라이언트"의 새로운 기능때문에 인터페이스가 추가되어있다면 어떻게 될까 ? 네트웍 객체는 다시 컴파일 되어야 할것이고, 이것을 사용하는 클라이언트들도 다시 컴파일 되야 할 것이다. 그리고 계속 이런일이 발생하면 네트웍 객체는 필요 이상으로 점점 방대해 질 것이다.

 이것이 위에서 언급한 클라이언트가 사용하지 않는 인터페이스 때문에 영향을 받는 것이다. 그렇다면 이와 같은 문제를 해결하기 위한 방법은 무엇이 있을까 ?

[그림 2]

 위와 같이 상속을 통해 공통부분을 관리하고 클라이언트에 종속적인 인터페이스는 따로 분리하여 객체로 관리하면 클라이언트가 다른 클라이언트와 독립적인 인터페이스를 가질수 있다.

이로서 객체지향 설계원칙 5가지에 대해 알아 보았다. 점점을 글을 쓸때마다 내용도 더 충실해 지고 내용전달도 잘 되것을 기대 하였지만, 현실은 그렇지 못했다. ㅡㅡ  이 놈의 귀차니즘 때문인지 시작한건 빨리 끝내야 겠다는 생각이 들어서 인지 서둘러 끝내는 느낌이다. ㅠㅠ

 지금까지 살펴본 객체지향 설계 5 원칙은 어찌 보면 가장 쉽고 간단한 원리이지만 막상 적용하려고 하면 상당히 어렵고 복잡해 진다. 익숙해 질때 까지 이 원칙을 계속 적용해 봐야 할것 같다. 그렇지만 항상 불변의 원칙은 없는 것이니까 너무 집착할 필요는 없을것 같다.