본문 바로가기

기타/객체지향의 탄생(2013)

객체지향의 탄생-ISP

 

  1. ISP(Interface Segregation Principle)

나는 옛날에 다세대 연립 주택에 살았다. 우리집 주변의 길은 개똥과 쓰레기가 적당히 엉켰고, 우리집 연립 주택 앞에는 각종 우편물과 전단지가 어지럽게 떨어져 있었다. 1층부터 3층까지 작은방이 덕지덕지 붙어 있었고, 그 속에 여러 사람들이 비좁게 살고 있었다. 이곳이 오래 있을 곳은 아니었지만, 그렇다고 이곳을 떠나기엔 아직 많은 시간과 노력이 필요했다.

 

연립 주택에 살면서 여러가지 불편한 일을 경험했다. 먼저 좁은집에 여러 사람이 붙어 사니, 종종 시끄러운 소리가 들렸다. 술취한 아저씨의 주정 소리도 들리고, 가족끼리 싸우는 소리도 많이 들렸다. 특히 한집의 가족이 자주 새벽에 싸우곤 했다. 삶에 지친 그들의 푸념 같은 싸우는 소리를 새벽에 듣는 일은 나를 고단하게 만들었다.

 

전기세, 수도세 계산하는 일이 불편했다. 전기세는 바로 옆집하고 우리집 전기세를 같이 계산해야 했다. 매달 계량기를 보고 엑셀을 편집하여 전기세를 산출하는 일은 몹시 귀찮았다. 수도세는 우리 연립주택 세대원을 1/N하여 세금을 걷었다. 이 일도 편한일은 아니었다.

 

무엇보다 집수리 할때가 가장 짜증났다. 우리 연립 주택은 노후한 주택이라 종종, 수도관에 물이 샌다든지, 보일러가 고장난다든지의 문제가 터졌다. 그럴때마다 설비기사가 와서 수리하곤 했다. 문제는 남의집에서 생긴 문제를 추적하다보니 우리집 방을 드러낼때도 있다는 것이다. 그때 느끼는 짜증은 말로 다할수가 없었다.

 

내가 이런 얘기를 할수 있는것은, ISP 설명에 적당한 비유를 찾다보니 연립주택에 비교하면 딱맞겠다는 생각이 들어서도 있고, 지금 글을 쓰는 시점에는 대출 끼어 집을 사서 이사 대기중이기 때문이다. 역시 세상 살려면 돈이 우선인것 같긴 하다.

 

 

ISP는 다세대 연립 주택에 사는 클래스들에게 새로운 자기 집을 마련해주는 것과 비슷하다.

 

[다세대 연립 주택 인터페이스와 이를 상속받은 클래스들의 그림]

 

이때 만약 3층 보일러 메소드가 크게 변경되었다고 하면 3층 세대 클래스뿐만 아니라 1층 클래스까지 모두 수정해야 한다.

 

[나만의 집 인터페이스로 분리했을때]

 

이렇게 자식 클래스가 쓰지 않는 인터페이스도 억지로 상속받는다면, 그 인터페이스는 분리해야 한다. 만약 자식 클래스에서 쓰지도 않는 메소드에 변경사항이 생겼을때, 그 자식 클래스도 어쩔수 없이 영향을 받기 때문이다. 마치 내가 빗길을 조심스럽게 걷고 있는데, 옆에 아무 인연 없는 자동차가 쌩~ 하니 지나가면서 빗물을 나에게 몽땅 튀긴다면 기분이 몹시 나쁠 것이다. 이런 일은 내 의지 와는 상관없는 불미스러운 일이다.

 

이런일 처럼 인터페이스를 자식 클래스가 상속받았는데, 자기가 쓰지도 않는 메소드에 변경이 생겼지만, 내 의지와는 상관없이 그 자식 클래스도 영향을 받아야 한다. 쓸데 없이 결합도가 높아지기 때문에 불미스러운 일이며, 이때는 인터페이스를 자식 클래스가 쓰는 메소드 범위에 맞게 분리해야 한다.

 

ISP 법칙은 SRP와 비슷하다. SRP는 클래스 관점에서 클래스가 하나의 일만 해야 된다고 가이드라인을 제시하며, ISP는 인터페이스 관점에서 '클래스가 자신이 사용하지 않는 메소드에 의존하면 안된다.' 는 기준에 따라 인터페이스를 바르게 사용하는 가이드라인을 제시해준다.

 

덧 ) 이 객체지향의 탄생 원고는 제가 책으로 내려다가 일단 잘 안되었는데요. 이유는 비문이 많다. 단락내 주제가 중복된다. 어떤 상황 설명을 과장한다.등 입니다. 그래도 원고를 일단 블로그에 몽땅 풀어보고 언젠가 제대로 교정해서 다시 도전할 생각입니다. 비문이 많다. 단락내 주제가 중복된다. 어떤 상황 설명을 과장한다. 이점을 감안해서 읽고 객체지향을 이해하는데 도움이 되셨으면 좋겠습니다. 의견도 주셨으면 좋겠습니다. 원고 조금만 교정하면 괜찮을것 같은 출판사 관계자분의 피드백도 환영합니다. 특별한 일 없으면 매주 월수 발행 예정입니다.