오트젝트 04 설계 품질과 트레이드 오프

[오브젝트: 코드로 이해하는 객체지향 설계] 를 읽고 정리한 내용입니다.

객체지향에서 올바른 설계는 올바른 객체에게 올바른 역할을 부여해야한다. 이 때 응집도와 결합도를 적절하게 저울질하면서 코드를 작성해야한다.

결합도와 응집도를 합리적인 수준으로 유지할 수 있는 중요한 원칙이 있다. 객체의 상태가 아니라 객체의 행동에 초점을 맞추는 것이다.

데이터 중심 설계

데이터 중심의 설계에서는 객체가 포함해야 하는 데이터에 집중한다

특히 Movie 클래스의 경우처럼 객체의 종류를 저장하는 인스턴스 변수(movieType)와 인스턴스의 종류에 따라 배타적으로 사용될 인스턴스 변수(discountAmount, discountPercent)를 하나의 클래스 안에 함께 포함시키는 방식은 데이터 중심의 설계 안에서 흔히 볼 수 있는 패턴이다.

• 데이터를 모아놓고 이들을 쉽게 오염시키 못하게 하려면 접근자와 수정자를 추가하면 된다. 자바스크립트에서는 get, set 키워드를 지원하고 추후에는 # private 키워드도 추가될 예정이다.

설계 트레이드 오프

캡슐화

상태와 행동을 하나의 객체 안에 모으는 이유는 객체의 내부 구현을 외부로부터 감추기 위해서다. 여기서 구현이란 나중에 변경될 가능성이 높은 어떤 것을 가리킨다. 객체지향이 강력한 이유는 한 곳에서 일어난 변경이 전체 시스템에 영향을 끼치지 않도록 파급효과를 적절하게 조절할 수 있는 장치를 제공하기 때문이다.

• 인터페이스는 구현과 반대로 변경이 적어야하기 때문에 안정적이다.

설계가 필요한 이유는 요구사항이 변경되기 때문이고, 캡슐화가 중요한 이유는 불안정한 부분과 안정적인 부분을 분리해서 변경의 영향을 통제할 수 있기 때문이다. 따라서 변경의 관점에서 설계의 품질을 판단하기 위해 캡슐화를 기준으로 삼을 수 있다.

응집도와 결합도

객체지향의 관점에서 응집도는 객체 또는 클래스에 얼마나 관련 높은 책임들을 할당했는지를 나타낸다.

객체지향의 관점에서 결합도는 객체 또는 클래스가 협력에 필요한 적절한 수준의 관계만을 유지하고 있는지를 나타낸다.

• 현실세계에서도 그렇듯 어떤 객체가 알맞지 않은 책임을 가지거나, 부적절한 관계를 유지하고 있으면 문제가 발생하기 마련이다.

응집도가 높을수록 변경의 대상과 범위가 명확해지기 때문에 코드를 변경하기 쉬워진다. 변경으로 인해 수정되는 부분을 파악하기 위해 코드 구석구석을 헤매고 다니거나 여러 모듈을 동시에 수정할 필요가 없으며 변경을 반영하기 위해 오직 하나의 모듈만 수정하면 된다.

• 응집도가 높은 아주 중요한 코드가 있을 때, 만약 이게 깨지게 된다면 큰 타격이 있기 때문에 응집도가 높으면서 서비스 코어로직인 경우에는 테스트 코드를 꼭 짜야할 것이다.

결합도 역시 변경의 관점에서 설명할 수 있다. 결합도는 한 모듈이 변경되기 위해서 다른 모듈의 변경을 요구하는 정도로 측정할 수 있다.

내부 구현을 변경했을 때 이것이 다른 모듈에 영향을 미치는 경우에는 두 모듈 사이의 결합도가 높다고 표현한다. 반면 퍼블릭 인터페이스를 수정했을 때만 다른 모듈에 영향을 미치는 경우에는 결합도가 낮다고 표현한다

캡슐화를 지키면 모듈 안의 응집도는 높아지고 모듈 사이의 결합도는 낮아진다. 캡슐화를 위반하면 모듈 안의 응집도는 낮아지고 모듈 사이의 결합도는 높아진다. 따라서 응집도와 결합도를 고려하기 전에 먼저 캡슐화를 향상시키기 위해 노력하라.

데이터 중심의 영화 예매 시스템의 문제점

캡슐화 위반

접근자와 수정자에 과도하게 의존하는 설계방식을 추측에 의한 설계 전략이라고 부른다.

• 객체간의 협력을 먼저 생각하지 않으면, 내부상태를 드러내느 코드를 짜게 된다.

객체 내부의 구현이 객체의 인터페이스에 드러난다는 것은 클라이언트가 구현에 강하게 결합된다는 것을 의미한다. 그리고 더 나쁜 소식은 단지 객체의 내부 구현을 변경했음에도 이 인터페이스에 의존하는 모든 클라이언트들도 함께 변경해야 한다는 것이다.

데이터 중심 설계의 문제점

데이터 중심의 설계가 변경에 취약한 이유는 두 가지다.  데이터 중심의 설계는 본질적으로 너무 이른 시기에 데이터에 관해 결정하도록 강요한다. 데이터 중심의 설계에서는 협력이라는 문맥을 고려하지 않고 객체를 고립시킨 채 오퍼레이션을 결정한다.

• 결국 계속 나오는 중요한 키워드는 협력이다.

데이터 중심의 설계를 시작할 때 던졌던 첫 번째 질문은 이 객체가 포함해야 하는 데이터가 무엇인가? 다. 데이터는 구현의 일부라는 사실을 명심하라.

안타깝게도 데이터 중심 설계에서 초점은 객체의 외부가 아니라 내부로 향한다. 실행 문맥에 대한 깊이 있는 고민 없이 객체가 관리할 데이터의 세부 정보를 먼저 결정한다. 객체의 구현이 이미 결정된 상태에서 다른 객체와의 협력 방법을 고민하기 때문에 이미 구현된 객체의 인터페이스를 억지로 끼워맞출 수밖에 없다. 

• 구현이 먼저 이루어지면, 협력을 하기위해 억지로 끼워맞추면서 인터페이스가 괴랄하게 변한다는걸 강조하는것 같다.

-알라딘 eBook <오브젝트> (조영호 지음) 중에