객체지향과 SOLID

솔리드란 단어를 최근에 들어 보았다. 객체지향과 솔리드 ? 내용을 보니 다른형태로 알고 있던 내용이였다. 좀더 객체지향에 대한 관심을 꾸준히 가졌다면 이제와서 들어보진 않았을거 같은데.... 나의 게으름에 반성중이다. 

솔리드는 객체지향의 5대 원칙의 앞글자만 따서 만든 것이 솔리드였다 SOLID ! 그리고 참 아이러니하게 내용을 하나하나 보면 평상시 내가 추구하는 코딩 원칙에 겹치는 부분들이 대부분 이였다. 나는 객체지향의 대한 전문가도 아니고 스페셜한 슈퍼 개발자도 아니다 보니 이런 솔리드같은걸 알고 썼다기 보다는 자바를 주로 사용하다보니 객체지향에 익숙해져 있었고 사용하면서 좀더 유지보수에 쉬운 형태와 좀더 다른사람들과 공유하기 쉽게 코드를 짤수 있을까를 스스로 꾸준히 고민했고 그런것들을 지키기위한 나만의 원칙을 만들었는데 나도 모르게 무의식적으로 생각하고 행동에 옴겼던 것들이 지금에서 객체지향의 5원칙들에 해당되는것들이 였다는걸 알고 헛웃음이 나왔다. 

 

1. 단일 책임의 원칙 

모든 클래스는 각각 하나의 임무만을 가져야만 한다. 

아주 중요한 내용이고 내가 가장 철칙으로 삼는 규칙이다. 예전에 만들어진 소스나 일부 품질 떨어지는 레거시 소스들을 보면 아주 흔하게 하나의 클래스가 1,000라인을 넘어가는 경우를 흔히 볼수 있다. 이유는 대부분 한 클래스에서 여러가지 기능을 담당하게 되고 그러다보니 한 클래스에 꾸준히 기능들을 추가하기 때문에 생기는 문제이다. 이럴경우 이 객체의 역할이 모호해지고 점점 알수 없는 클래스가 되어서 유지보수시 손가락이 부서지게 스크롤 하게 되는 사태가 벌어진다. 예전에 개발자들과 논의할때 클래스의 역할을 단순화 하는게 좋다고 꾸준히 주장했고 실제로 많은 클래스들을 역할에 맞게 분류 하여 긍정적인 효과를 보았다.

 

2. 개발 폐쇄의 원칙 

확장은 찬성 수정은 반대! 참어려운 부분이다. 변경과 수정은 불가피한 영역이지만 최대한 수정을 반대하고 기능은 추가가 쉽게 되어야한다는 원칙이다. 가장 이상적인 구조가 아닌가 싶다. 일단 내가 경험한것중에 가능 이 법칙을 준수할수 있는건 클래스를 정의할때 최대한 인퍼테이스를 활용하고 필요한 액션에 대한것들은 재정의 하도록 하는것이다. 말로 설명 하면 어려운 내용이지만 상속과 인테페이스를 잘이해하고 있고 잘 사용할수 있다면 충분하다고 생각이 든다. 

 

3. 리스코프 치환의 원칙

자식은 부모를 대신할수 있다! 상속에 대한 이해가 필요할거 같다. 부모와 자식 앞서 말한 개발폐쇄의 원칙과 어느정도는 연장선에 있다고 개인적으로 생각하나. 원래 부모 클래스가 들어간 자리에 자식클래스가 들어가도 로직상에 문제가 발생하지 않으면 된다.

 부모와 자식의 관계지만 집합으로 봤을때 자식클래스에 부모클래스가 속한 구성으로 해야한다는 의미이고 당연히 자식클래스가 더 큰 범위를 처리하기 때문에 당연하게도 대신할수 있다고 보는것이다. 개인적으로 상속이나 인터페이스를 남발하는것을 좋아 하지 않는데 이해도가 없는 개발자가 볼경우 코드분석이 어렵기 때문이다 하지만 꼭 필요한 경우라면 부모 클래스는 단순한 인터페이스 수준으로 만들고 자식클래스에서 많은것들을 하려고 노력하는 편이다. 하지만 솔직히 잘 이해하기 힘든 법칙인거 같다. 

 

4. 인터페이스 분리의 원칙

클래스는 다중인격이여야 한다!  내용을 찾아보면 살짝 이해하기 힘든 부분들이 있다. 하나의 인터페이스보다는 여러개의 인터페이스가 낫다는 문장이 많이 노출 될것이다. 뭔가 위에서 서술한 1원칙은 단일 원칙이 중요하다고 강조하는데 이 원칙은 뭔가 다중으로 가야한다는 원칙의 뉘앙스를 풍긴다. 개인적으로 정의한것이 옳은지는 모르지만 나는 이렇게 이해하기로 했다. 

 

하나의 클래스를 상속 받는것이 아니라 인터페이스를 상속하여  부모클래스의 성격의 영향을 덜받도록 하고 인터페이스 다중 상속을 통해서 필요한 영역만 부분집합으로 사용하는것을 지향한다. 

 

개인적으로는 상속보다는 인터페이스를 더 선호하는 성향이라 이 원칙에 대해서는 읽어보면서 오히려 역으로 이래서 인터페이스를 내가 썼었구나 라는 생각이 들게 하는 원칙이였다. 그리고 막연하게 클래스를 통으로 상속받는건 알수없는 무거움이 있다고 느꼈고 무겁다는것은 유연하기 힘들다는 경험을 통한 막연한 생각에 인터페이스를 활용을 많이 했고 다중상속이 지원 안되는 자바이기에 다중 인터페이스가 가능한 인터페이스를 본능적으로 선호한 부분도 있던것 같다. 

 

5. 의존 역전의 원칙 

 의존성을 가져야할때 안변하는 것들을 선호 할것! 객체지향에 대한 원칙이다 보니 아무래도 인터페이스, 추상 클래스 등의 이야기들이 자주 언급 하는것 같다. 정확하게 어떤걸 의미하는지 서칭해보니 간단하게 내용들을 요약해보면 구체적인 클래스 보다는 인터페이스나 추상클래스 를 이용하여 관계를 맺으라는 의미인거 같다.

 의존역전의 원칙을 위해 Layering 이란 방법을 보통 사용하는데 상위 레이어와 하위 레이어가 직접적인 의존성을 가지는것이 아니라 그상에 추상레벨의 인터페이스 혹은 클래스를 두어서 상위,하위 레이어의 직접적 의존성을 없에는 형태를 만든다. 모양을 잘보면 요즘 많이 볼수 있는 아키텍쳐중에 3tier Architecture 구성이란것이 있다. 객체지향이란것이 꼭 프로그래밍에만 적용가능한것이 아니라 어떻게보면 시스템 구성에도 충분히 활용가능하지 않을까 하는생각이 들었다 MSA 도 보면 각 요소들은 작은단위의 단순한 서비스를 담당하고 그것들을 서로 의존성을 최소화 하여 구성하는것이라는 관점에서 보면 확실히 전혀 연관없는 내용이라고만 볼수 없을거 같다. 

 

p.s

원칙들의 내용을 하나하나 살펴보면 대부분 인터페이스의 다중화 클래스의 단일화를 통한 단순화 등  개인적 해석으로는 객체지향 원칙이란건 결국엔 그 베이스는 클래스의 성격대한 올바른 역할 정의와 유지보수/재사용이 가능한 형태의 서비스를 만드는것이 목적이 아닌가 하는 생각이 든다. 결국엔 MSA 나 클린코드들도 비슷한 니즈에서 출발했을것이고 객체지향은 오래된 개발방식이며 앞으로도 오래동안 중요한 개념으로 사용되지 않을까 하는 생각이 든다. 

 실제 업무를 해보면 회사별로 객체지향적인 서비스를 만들기 힘들경우가 많다. 객체지향에 대한 지식이 없는 경우이거나 객체지향은 비용이 너무 많이 든다 굳이 그런것들 지켜서 만들지 않아도 서비스는 돌아갈수 있다 등등 이유는 많은것 같다. 여태 프로그래머를 하면서 꼭 방법론들을 지켜야하나에 대한 의구심은 일시작할때 부터 느끼고있었고 그 의구심이 해결되는건 생각보다 오래 걸린것 같다. 개인적으로는 5년정도 지나면서 왜 이런것들이 필요한지에 대한 필요성을 느꼈고 조금씩 스스로 사용해보고 경험치를 쌓아보려고 노력했던것 같다.  팀원들과 어느범위까지 적용할지에 대해 논의하고 그런것들에서 소소한 재미도 느끼고 보람도 느꼈던거 같다. 

방법론은 정말 방법론이다. 이론일 뿐이지 정답은 아니다. 하지만 정답은 아니라고 아주 무시할만것은 아니라고 본다. 아직 객체지향보다 더 획기적인 방법이 나왔다고 보기힘들다 그렇다면 현시대의 최선을 선택하는게 좋지 않나 싶다. 객체지향이 지금은 보편적으로 널리 쓰이지만 나중에 더 좋은 방법론이 나온다면 다들 그 방법론을 사용할것이라고 생각한다. 객체지향 기본 원리를 이용해서 소프트웨어를 유연하게 만들고 좀더 긴 라이프사이클을 가질수있는 환경을 만든다면 현재시점에서는 아주 좋을것 같다.