4장 - 설계 품질과 트레이드오프

개요

이번 장에서는 데이터 중심의 설계의 문제점을 이해하기 위해 몇 가지 알아야 할 용어들과 데이터 중심 설계에 어떤 문제점이 있는지에 대해 다룹니다.

 

 

시스템을 분할하는 방법

• 사용자가 사용할 시스템을 구현하기 위해 설계 관점에 따라 시스템을 다르게 분할하여 구현합니다.

 

시스템을 분할하기 위해 데이터와 책임 중 어떤 것을 선택해야 할까?

• 책의 저자는 데이터가 아니라 책임에 초점을 맞춰야 한다고 합니다.

 

책임에 초점을 맞춰야 하는 이유는 무엇일까?

• 객체의 상태는 구현에 속하며 구현은 불안정하기 때문에 변하기 쉽습니다.
• 객체의 상태가 객체 분할의 초점이 되면 구현 세부 사항이 객체의 인터페이스에 스며들어 캡슐화의 원칙이 무너지게 됩니다.
• 즉, 상태가 변경되면 인터페이스도 변경되어 해당 인터페이스에 의존하는 모든 객체에 영향을 미칩니다.
• 결과적으로 데이터 중심의 설계는 변경에 더 취약합니다.
• 반면 객체의 책임은 인터페이스의 일부입니다.
• 책임을 강조하고 안정적인 인터페이스 뒤에 필요한 상태를 캡슐화함으로써 개체는 구현 변경으로 인한 파급 효과를 최소화할 수 있습니다.
• 따라서 책임에 초점을 맞추면 상대적으로 변경에 안정적인 설계를 얻을 수 있게 됩니다.

 

설계에서 생각해 볼 내용

• 데이터 중심의 설계는 객체 내부에 저장되는 데이터를 기반으로 시스템을 분할하는 방법입니다.
• 책임 중심의 설계가 "책임이 무엇인가?"를 묻는 것으로 시작한다면 데이터 중심의 설계는 "객체가 내부에 저장해야 하는 데이터가 무엇인가?"를 묻는 것으로 시작합니다.
• 만약 객체의 책임을 결정하기 전에  "이 객체가 포함해야 하는 데이터는 무엇인가?" 이런 질문의 반복에 휩쓸려 있다면 데이터 중심의 설계에 매몰돼 있을 확률이 높습니다.
• 객체지향의 가장 중요한 원칙은 캡슐화이므로 내부 데이터가 객체의 엷은 막을 빠져나가 외부의 다른 객체들을 오염시키는 것을 막아야 합니다.
• 이를 달성할 수 있는 가장 간단한 방법은 내부의 데이터를 반환하는 접근자와 데이터를 변경하는 수정자를 추가하는 것입니다.

 

 

설계 트레이드오프

• 데이터 중심 설계와 책임 중심 설계의 장단점을 비교하기 위해 캡슐화, 응집도, 결합도의 의미를 살펴봅니다.

 

캡슐화

• 캡슐화는 외부에서 알 필요가 없는 부분(내부 구현)을 감춤으로써 대상을 단순화하는 추상화의 한 종류입니다.
• 여기서 구현이란 나중에 변경될 가능성이 높은 어떤 것을 가리킵니다.
• 객체를 사용하면 변경 가능성이 높은 부분은 내부에 숨기고 외부에는 상대적으로 안정적인 부분만 공개함으로써 변경의 여파를 통제할 수 있습니다.
• 변경될 가능성이 높은 부분을 구현이라 부르고 상대적으로 안정적인 부분을 인터페이스라고 부릅니다.
• 객체를 설계하기 위한 가장 기본적인 아이디어는 변경의 정도에 따라 구현과 인터페이스를 분리하고 외부에서는 인터페이스에만 의존하도록 관계를 조절하는 것입니다.
• 객체지향 설계의 가장 중요한 원리는 불안정한 구현 세부사항을 안정적인 인터페이스 뒤로 캡슐화하는 것입니다.

 

응집도

• 응집도는 모듈에 포함된 내부 요소들이 연관돼 있는 정도입니다.

• 응집도가 높은 설계에서는 하나의 요구사항 변경을 반영하기 위해 오직 하나의 모듈만 수정하면 되며, 응집도가 낮은 설계에서는 하나의 원인에 의해 변경해야 하는 부분이 다수의 모듈에 분산돼 있기 때문에 여러 모듈을 동시에 수정해야 합니다.
• 따라서 응집도가 높을수록 변경의 대상과 범위가 명확해지기 때문에 코드를 변경하기 쉬워집니다.

 

결합도

• 결합도는 의존성의 정도를 나타내며 다른 모듈에 대해 얼마나 많은 지식을 갖추고 있는지 나타내는 척도입니다.

• 낮은 결합도를 가진 설계에서는 모듈 a를 변경했을 때 오직 하나의 모듈만 영향을 받는다는 것을 알 수 있습니다.
• 반면 높은 결합도를 가진 설계에서는 모듈 a를 변경했을 때 4개의 모듈을 동시에 변경해야 합니다.
• 따라서 결합도가 높으면 높을수록 함께 변경해야 하는 모듈의 수가 늘어나기 때문에 변경하기가 어려워집니다.

 

 

데이터 중심의 설계의 문제점

• 데이터 중심의 설계는 객체의 내부 구현을 인터페이스의 일부로 만드는 경향이 있어 캡슐화 문제가 발생할 수 있습니다.
• 따라서 책임 중심의 설계에 비해 응집도가 낮고 결합도가 높은 객체들을 양산하게 될 가능성이 높습니다.
• 데이터 중심 설계가 가진 대표적인 문제점으로는 응집도, 결합도, 캡슐화가 있습니다.

 

캡슐화 위반

• 객체가 사용될 문맥을 추측할 수밖에 없는 경우 개발자는 어떤 상황에서도 해당 객체가 사용될 수 있게 최대한 많은 접근자 메서드를 추가할 수 있습니다.
• 접근자와 수정자에 과도하게 의존하는 설계 방식을 추측에 의한 설계 전략이라고 부릅니다.
• 이 전략은 객체의 협력을 고려하지 않고 객체가 다양한 상황에서 사용될 수 있을 것이라는 막연한 추측을 기반으로 설계를 진행합니다.
• 결과적으로 내부 상태를 노출하는 메서드들을 최대한 많이 추가해야 한다는 압박이 있으며, 그 결과 대부분의 내부 구현이 퍼블릭 인터페이스에 그대로 표시됩니다.
• 이는 캡슐화 원칙을 위반하는 변경에 취약한 설계를 얻게 됩니다.

 

높은 결합도

• 데이터 중심의 설계는 접근자와 수정자를 통해 내부 구현을 인터페이스의 일부로 만듭니다.
• 객체 내부의 구현이 객체의 인터페이스에 드러난다는 것은 클라이언트와 객체 구현 간에 강한 결합을 생성하는 것을 의미합니다.
• 이 결합도로 인해 어떤 데이터 객체를 변경하더라도 제어 객체를 변경할 수밖에 없습니다.
• 이 설계는 전체 시스템을 하나의 거대한 의존성 덩어리로 만들어 버리기 때문에 어떤 변경이라도 일단 발생하고 나면 시스템 전체가 요동칠 수밖에 없습니다.

 

낮은 응집도

• 어떤 요구사항 변경을 수용하기 위해 하나 이상의 클래스를 수정해야 할 때 응집도가 낮다고 말합니다.
• 각 모듈의 응집도를 살펴보기 위해서는 코드를 수정하는 이유가 무엇인지 살펴봐야 합니다.
• 낮은 응집도는 두 가지 측면에서 설계에 문제를 일으킵니다.
• 첫 번째로 변경의 이유가 서로 다른 코드들을 하나의 모듈 안에 뭉쳐놓았기 때문에 변경과 아무 상관이 없는 코드들이 영향을 받게 됩니다.
• 두 번째로 하나의 요구사항 변경을 반영하기 위해 동시에 여러 모듈을 수정해야 합니다.

 

 

마무리

오늘은 오브젝트 책 4장을 스터디하면서 중요하다고 생각한 부분을 정리해 보았습니다.

4장을 읽고 나니 어렴풋이 알던 데이터 중심 설계의 단점들을 좀 더 명확하게 알게 되어서 좋았다고 생각이 듭니다.

데이터 중심의 설계 방식의 문제들을 책임 지향 설계 방식에서는 어떻게 해결할 수 있을지? 궁금증이 생기네요.

이번 포스팅은 마무리하면서 다음 포스팅에서 뵙겠습니다.

 

 

참고

http://www.yes24.com/Product/Goods/74219491

오브젝트 - YES24