오브젝트(3)

설계 품질과 트레이드 오프

​

개인적으로 많은 생각을 하게 만드는 단원이 아닐까 싶다. 실질적으로 모든 내용에 대해서 완벽한 정답이란 없다.

이런 부분들에 대해서 어디에서건 나오는 단어 즉 ‘trade off’다.

​

앞서 이야기 했듯이 Java를 이용해서 프로그래밍 하면서 Java는 객체지향 언어라는 것을 알고 있을테지만, 실질적으로 책과 마주하는 나는 어색한게 사실이다. 앞서 봤던 책 ‘객체지향 사실과 오해’ 에서 언급 되었던 역할, 책임, 협력 이라는 단어가 등장한다.

​

“객체지향 설계의 올바른 객체에 올바른 책임을 할당하면서 낮은 결합도와 높은 응집도를 가진 구조를 창조하는 활동 이라고 안내한다.”

​

우리는 이러한 방법을 찾기 위해 많은 부분으로 공부하고 그것을 적용해보려 노력한다.

if문을 제거하여 객체지향적으로 코드를 작성하는 법(링크)이나 책임 할당을 좀더 잘 하기 위해서 DDD(링크)를 공부하고 도메인 단위로 나누는 법 해본다던가. 그 밖에 여러 디자인 패턴을 공부한다던지 여러 방면으로 살펴본다.

​

이러한 활동들이 결국 객체지향 언어를 사용하고 있는 우리들에게 걸맞는 철학을 잘 이해하고 코드에 적용해보고 싶은 활동이라고 생각한다.

​

(개인적으로 아마 다들 책이나 고민해가면서 해답을 잘 찾아가고 있다고 생각한다.)

​

그렇다면 왜 우리는 이러한 것에 익숙하지 못했을까?

​

책에서는 훌륭한 객체지향 설계는 데이터가 아니라 책임에 초점을 맞춰야 한다고 한다.

​

객체의 상태는 구현에 속하고, 구현은 불안정하기 때문에 변하기가 쉽다. 이렇게되면 세부 사항이 객체의 인터페이스에 스며들게 되어 캡슐화의 원칙이 무너진다고 한다. 이러한 인터페이스 변경등이 의존하는 모든 객체에 영향이 퍼지므로 변경에 취약하게 된다고 한다.

​

책임을 초점을 맞춘다는 것은 설계한 객체가 어떤 역할을 할지를 나눈다는 것이고, 캡슐화라는 것은 결국 결합도를 낮추는 것이다. 이러한 부분에 대해서는 아마 여러 상황에서 겪었을 거라 생각된다.

​

데이터 중심 설계에 기반한 클래스를 책에서 나타내준다.

​

익숙한 Value Object 같은 클래스와 Getter, Setter를 모두 포함하고 있다. 한마디로 특정 데이터를 표현한 클래스를 데이터 중심 설계라고 나타내고 있다.

​

데이터 중심 설계에서는 객체가 포함해야 하는 데이터에 집중한다. 클래스에 작성된 Setter 등을 통해서 내부 객체 상태에 접근할 수 있도록 표현 되기 때문에 객체의 엷은 막을 빠져나가 외부의 다른 객체들을 오염시킬 수 있다고 한다.

​

이러한 부분은 불변형 데이터와도 관련된 내용일 수 있으며, 책임에 대해 설명하는 것이니 곧 역할에 초점을 맞춘다면 이러한 상태 값을 변경하는 접근 방법으로 구현되지 않는다는 것 같다.

​

이러한 데이터 중심 설계에서 객체지향 설계로 변경하기 위하여 3가지를 이야기한다.

​

캡슐화

​

상태와 행동을 하나의 객체 안에 모으는 이유는 객체의 내부 구현을 외부로부터 감추기 위해서다. 변경 가능성이 높은 부분은 내부에 숨기고 외부에는 상대적으로 안정적인 부분만 공개함으로써 변경을 통제할 수 있다.

​

변경에 안정적인 부분을 인터페이스라고 하고, 변경될 가능성이 높은 부분을 구현이라고 한다.

​

캡슐화는 곧 변경 가능성이 높은 부분을 객체 내부로 숨기는 추상화 기법이다.

​

응집도와 결합도

​

응집도는 모듈에 포함된 내부 요소들이 연관돼 있는 정도를 나타낸다. 모듈 내의 모든 요소들이 하나의 목표를 위해 긴밀히 협력한다면 그 모듈은 높은 수준의 응집도를 가진다.

​

결합도는 의존성의 정도를 나타내며 다른 모듈에서 얼마나 많은 지식을 갖고 있는지를 나타내는 정도다.

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

​

좋은 설계란 오늘의 기능을 수행하면서 내일의 변경을 수용할 수 있는 설계다.

-> 예전에 자주 설계가 바뀌면 화냈던 나의 모습이 오버랩되는데 참 어리석었다.

그리고 높은 응집도와 낮은 결합도를 추구해야 한다.

-> 결국 역할과 책임을 잘 나누게 되면 좋은 설계를 할 수 있지 않을까 라는 것이 내 생각이다.

​

데이터 중심 설계의 문제점

​

• 본질적으로 너무 이른 시기에 데이터에 관해 결정하도록 강요한다.

• 협력이라는 문맥을 고려하지 않고 객체를 고립시킨 채 오퍼레이션을 결정한다.

​

​