CH05 객체 지향 설계 5 원칙 - SOLID
좋은 설계란
여러 답이 나올 수 있겠지만 객체지향의 사실과 오해 책에서 여러차례 언급되었듯이 '수정 비용이 적은' 설계라고 생각한다. 수정 비용이 적다는 말은 신규 기능이 있을때 다른 것들을 고친다던가 하는 비용이 최소화된 설계인 것이다. 즉, 신규 기능을 개발하여 붙이기 용이한 구조라는 것이다. 한편으로 기존의 기능에 변경 사항이 발생하더라도 기존의 것들에 영향이 최소화된 구조라서 손쉽게 변경할 수 있다는 것이다. 더하든, 덜어내든, 변경시킴에 있어 그 비용이 적은 것을 의미한다.
보통 높은 응집도와 낮은 결합도를 가진 설계가 수정 비용이 적다고 생각한다.
높은 응집도와 낮은 결합도를 추구해야하는 이유
응집도란 무엇이며 응집도가 높으면 뭐가 좋은가
어떠한 객체의 응집도가 높다는 것은 해당 객체에 주어진 책임이 분명하고, 오로지 이 책임의 완벽한 수행을 위해서 객체가 설계되어 있다는 것을 의미한다. 이것을 조금 확장적으로 생각해보면 각 객체가 응집도가 높다는 것은 곧 각 객체는 다른 객체들과 책임이 겹치지 않고 각자 맡은 바에 대해서만 집중하고 있다는 것이다. 이는 곧 수정이 발생 했을때 응집도가 명확하므로 수정사항에 해당하는 특정 객체만 변경하면 될 확률이 높다는 것을 의미한다.
결합도란 무엇이며 결합도가 낮으면 뭐가 좋은가
결합도란 서로 다른 객체간의 의존도를 이야기한다. 객체 지향의 세계에서 소프트웨어는 곧 객체들의 협력이다. 객체들의 협력은 메세지를 통해서 이뤄지고 각 객체는 최대한 자율성이 보장되어야 수정비용이 가장 낮은 설계가 이뤄진다. 그런데 여기서 결합도가 높다는 것은 객체의 자율성을 떨어트리는 것이다.
특정 객체가 다른 객체에게 'A 해줘' 라고 협력을 요청하고 해당 객체는 자신의 것에만 집중해야하는데 'A를 하는데 이렇게 저렇게 해서 최종적으로 이렇게 줘' 라고 하는 것이 결합도가 높아지는 예시이다. 그러면 결국 해당 기능에 대한 수정이 발생 했을때 수정의 범위가 넓어지고 다른 여러 객체들도 이 객체에 의존하고 있다면 수정 비용은 그만큼 늘어난다.
SOLID 는 결국 무엇인가
SOLID 는 객체 지향 프로그래밍의 세계에서 보다 좋은 설계(높은 응집도, 낮은 결합도)를 위한 방법론 및 원칙들이다.
SRP(Single Responsibility Principle, 단일 책임 원칙)
의미
객체의 책임은 하나여야한다.
어떻게 SRP 를 달성할까
객체의 책임을 '명확하게' 한다. 결국 실제 비즈니스 도메인의 문제를 해결하기 위해서 객체 모델링을 하는 것인데 이 과정에서 어떠한 객체를 만든다면 해당 객체는 반드시 '무엇을 담당시키기 위한' 모델링 의도가 있어야 하며 이 의도가 세밀하여야 한다. 이 논리적 단위가 추상적이지 않고 분명하고 명확해야한다.
그리고 해당 객체는 최대한 자율적이어야 한다. 객체는 결국 메세지를 통해서 협력을 요청받게 되고 이를 수행하는데 이 과정에서 최대한 다른 객체들의 침범을 받지 않고 자율적으로 처리할 수 있는 구조여야 한다.
메소드 단위에서도 SRP 는 적용된다
책에서 좋은 예시를 들고 있는데, 메소드 내에서도 if 문에 따라 분기되는 구조가 있다면 클래스 자체를 구분하여 구현체를 따로 만들어서 SRP를 지킬 수 있도록 하자.
OCP(Open-Closed Principle, 개방-폐쇄 원칙)
의미
확장에 열려있고 변경에 닫혀 있어야 한다. 책에서는 '자신의 확장에는 열려있고, 주변의 변화에 대해서 닫혀있어야 한다' 고 표현하고 있다. 개인적으로 오히려 좀 왜곡된 표현 같다는 생각이 들었다. 그냥 소프트웨어 시스템 자체가 확장에 열려있고 변경에 닫혀있어야 한다고 이해하는 것이 더 적절한 것 같다.
확장에 열려있다는 의미는 확장이 그만큼 용이하다는 것이다. 새로운 요구사항이 있을때 손쉽게 확장시킬 수 있다는 것이다. 한편 변경에 닫혀 있다는 말은 변경을 허용하지 않겠다는 것이 아니라, 변경 발생시 기존의 것들이 '닫혀'있어서 피해를 받지 않는다는 이야기이다. 변경 발생으로 인해서 기존의 코드들이 추가적인 변경이 발생할 일이 없어야 한다는 것이다.
어떻게 OCP 를 달성할까
SOLID 각 규칙들이 의미적으로는 구분되어도 결국 달성하는 방법은 비슷한 측면이 많다. OCP도 마찬가지이다.
OCP를 달성하기 위해서는 추상화를 최대한 이용해야 한다. 변경 및 확장 가능성이 있는 것이 있다면 이에 의존하는 클라이언트 쪽에서는 구체적 객체에 의존하지 않고 추상화된 계층에 의존시키고, 각 세부적 니즈는 구현체에서 풀어내는 형태로 OCP 를 달성한다. 결국 뒤에 이어질 DIP 와 맥락이 이어진다.
LSP(Liskov Substitution Principle, 리스코프 치환 원칙)
의미
상위 타입의 객체를 하위 타입의 객체로 치환해도 프로그램의 동작이 유지되어야 한다.
이게 왜 좋은 설계에 도움이 되는걸까
객체지향의 사실과 오해에서도 나왔듯이 다형성이란 동일한 메세지에 대해서 다양하게 행동하게 되는 객체들의 모습을 의미한다. LSP를 지켰다는 것은 동일한 메세지(협력 요청)에 대해서 A도 B도 C도 모습은 다르지만 협력이라는 근본적은 요구에는 응답하는 것이므로 결국 느슨한 결합을 띄게 된다.
어떻게 LSP 를 달성할까
상위, 하위 클래스 관계는 '분류'의 관점이어야지 '위계'여서는 안된다.
ISP(Interface Segregation Principle, 인터페이스 분리 원칙)
의미
넓은 인터페이스를 특화된 인터페이스로 분리하는 것이 핵심이다.
어떻게 ISP 를 달성할까
클라이언트에는 오로지 필요한 인터페이스만 제공하면 된다. 그만큼 인터페이스들 각각이 명확한 책임을 정의하고 있어야 할 것이며 클라이언트가 이것에 의존하려면 그만큼 정말 합당한 이유가 있어야한다.
DIP(Dependency Inversion Principle, 의존역전원칙)
의미
하위 수준의 모듈은 상위 수준의 모듈에 의존해서는 안 되고, 상위 수준의 모듈은 추상화에 의존해야 한다는 원칙
고수준, 저수준이 무슨 수준을 말하는건가
DIP 에서 이게 핵심이라고 생각한다. 여기서 말하는 수준이란 '추상화의 수준'을 의미한다. 그럼 고수준은 추상화 수준이 매우 높다는 말이 되는데, 추상화 수준이 높은 것이 추상화 수준이 낮은것에 의존한다는 말이 된다.
추상화 수준이 높다는 말은 무슨 말일까? 객체의 책임을 문장으로 표현해보자. 예를 들어서 소프트웨어가 '데이터베이스에 접속해야한다' 는 표현이 있고, 'MySql 에 접속해야한다', 'Oracle 에 접속해야한다' 라는 표현들이 있고 이를 비교해보자. 데이터베이스 벤더사가 무엇이 되었든 가장 큰 맥락에서 '데이터베이스에 접속해야한다' 는 문장이 가장 추상화된 문장이다. 반대로 다른 문장이 구체화된 문장이다.
어떻게 DIP 를 달성할까
'도메인 주도 개발 시작하기 > CH02 아키텍처 개요' 에서 이미 DIP 에 대해서 정리를 해두었다. 복습시 해당 파트를 다시 보기로 한다. 일단 거기서 사용했던 이미지 하나를 여기에도 첨부한다. 결국 추상화를 이용해서 의존의 방향을 역전시키는 것이 핵심이다.
왜 이게 '역전'된다는 걸까? 가 생각나지 않는다면, 아래 DIP 가 실현된 설계에서 중간에 있는 인터페이스 레이어를 제거하고 고수준 모듈이 저수준에 바로 의존 시킨뒤 다시 인터페이스를 넣어보자. 그러면 의존 방향이 역전된다.
Last updated
