14 일관성 있는 협력

14장에서는 이전 장에서 배운 다형성, 상속등을 바탕으로 실제 코드에 어떻게 적용하는지에 배웠습니다. 14장에서는 초반에 이전 장에서 작성한 코드를 바탕으로 어떻게 해야 '일관성'을 지키며 협력을 하였는지에 대해 이야기를 하였습니다. 저는 이전 장에서 보았는 코드를 일관성 있게 리팩토링하는 것에 집중하며 보기보단 이후에 나오는 개념적인 부분에 대해 더 집중하며 보았습니다.

---

일관성은 설계에 드는 비용을 감소시킨다.

일관성의 중요성에 대해 이야기를 하고 있습니다. 저는 최근 프로젝트에서 백엔드 개발을 희망하는 학우와 협업을 해본적이 있으며 일관성의 필요성을 절실히 느꼈습니다. 이후에 나올 내용까지 요약하자면 일관성은 다른 코드에 대한 이해를 바탕으로 새로운 코드에 대해서 쉽게 이해할 수 있게 도와주기에 중요하다 입니다.

01 핸드폰 과금 시스템 변경하기

구간별 방식 구현하기

현재 구현의 가장 큰 문제점은 이 클래스들이 유사한 문제를 해결하고 있음에도 불구하고 설계에 일관성이 없다는 것이다.
...
비일관성은 두 가지 상황에서 발목을 잡는다 하나는 새로운 구현을 추가해야 하는 상황이고, 또 다른 하나는 기존의 구현을 이해해야 하는 상황이다.
...
결과적으로 세 가지 기본 정책에 대한 세 가지 서로 다른 구현 방식이 존재하는 것이다.
...
일관성 없는 코드가 가지는 두 번째 문제점은 코드를 이애하기 어렵다는 것이다.
...
유사한 요구사항이 서로 다른 방식으로 구현돼 있다면 요구사항이 유사하다는 사실 자체도 의심하게 될 것이다.
...
코드 재사용을 위한 상속은 해롭다.

일관성이 필요한 이유에 대해 이야기하고 있습니다. 만약 일관성이 부족하다면 코드를 이해하는데에 있어 많은 어려움을 겪을 것이고 개인적인 생각이지만 스파게티 코드가 되어가는 초반부라고 생각합니다. 그리고 일관성을 구현하기 위한 상속에 대해 이야기하자면 '코드 재사용'이 아닌 '코드의 계층 구조'를 만들기 위해 사용되어야 합니다.

02 설계에 일관성 부여하기

일관성 있는 설계를 만드는 데 가장 훌륭한 조언은 다양한 설계 경험을 익히라는 것이다.
...
일관성 있는 설계를 위한 두 번째 조언은 널리 알려진 디자인 패턴을 학습하고 변경이라는 문맥 안에서 디자인 패턴을 적용해 보라는 것이다.
...
- 변하는 개념을 변하지 않는 개념으로부터 분리하라.
- 변하는 개념을 캡슐화하라.

이전 챕터가 일관성이 필요한 이유에 대해 짚어줬다면 이번 챕터는 일관성을 구현하는 방법에 대한 챕터 입니다. 그리고 이러한 일관성을 사용하기 쉽게 만들어 놓은 방법인 디자인 패턴에 대해 이야기를 합니다.

 

조건 로직 대 객체 탐색

이 설계가 나쁜 이유는  변경의 주기가 서로 다른 코드가 한 클래스안에 뭉쳐있기 때문이다.
...
객체지향에서 변경을 다루는 전통적인 방법은 조건 로직을 객체 사이의 이동으로 바꾸는 것이다.
...
지금까지 살펴본 것처럼 조건 로직을 객체 사이의 이동으로 대체하기 위해서는 커다란 클래스를 더 작은 클래스들로 분리해야 한다.
...
간단하게 말해서 단일 책임 원칙을 따르도록 클래스를 분리해야 한다는 것이다.
...
일관성 있는 협력을 위한 지침1
- 변하는 개념을 변하지 않는 개념으로부터 분리하라
일관성 있는 협력을 위한 지침2
- 변하는 개념을 캡슐화하라.
...
변경에 초점을 맞추고 캡슐화의 관점에서 설계를 바라보면 일고나성 있는 협력 패턴을 얻을 수 있다.

변하는 개념을 분리하는 방법으로는 별도의 서브타입으로 분리하고 이후 서브타입들을 캡슐화한 것입니다. 그리고 이렇게 캡슐화 된 객체들에 대해 공통적인 추상화를 찾아 해당 추상화에 의존하도록 만드는 것입니다. 그러므로 추상화의 품질이 높을수록 협력의 품질을 결정하다 생각합니다. 결국 협력은 캡슐화를 통해 이루어집니다.

 

캡슐화 다시 살펴보기

캡슐화란 변하는 어떤 것이든 감추는 것이다.
- 데이터 캡슐화: 클래스는 내부에 관리하는 데이터를 캡슐화해야 한다.
- 메서드 캡슐화: 클래스의 내부 행동을 캡슐화 하고 있는 것이다.
- 객체 캡슐화: 객체와 객체 사이의 관계를 캡슐화한다. 눈치가 빠른 사람이라면 객체 캡슐화가 합성을 의미한다는 것을 눈치챘을 것이다.
- 서브타입 캡슐화: 서브타입의 종류를 캡슐화하고 있는 것이다. 눈치가 빠른 사람이라면 서브타입 캡슐화가 타형성의 기반이 된다는 것을 알 수 있을 것이다.
...
변하는 부분을 분리해서 타입 계층을 만든다.
...
변하지 않는 부분의 일부로 타입 계층을 합성한다.

캡슐화의 관점에서 일관성 있게 코드를 작성하는 방법입니다. 캡슐화를 다시 보면 캡슐화는 변하는 모든 것을 숨기는 것이고 이것에는 데이터, 메서드, 관계등 모든 '개념'을 숨기는 것입니다. 그리고 데이터 캡슐화와 메서드 캡슐화는 개별 객체에 대한 변경을 관리하기 위해 사용하며 객체 캡슐화와 서브타입 캡슐화는 협력에 참여하는 객체들의 관계에 대한 변경을 관리하기 위해 사용합니다.

03 일관성 있는 기본 정책 구현하기

구체적인 협력 구현하기

기본 정책을 추가하기 위해 규칙을 지키는 것보다 어기는 것이 더 어렵다는 점에 주목하라. 일관성 있는 협력은 개발자에게 확장 포인트를 강제하기 때문에 정해진 구조를 우회하기 어렵게 만든다.
...
유사한 기능에 대해 유사한 협력 패턴을 적용하는 것은 객체지향 시스템에서 개념적 무결성을 유지할 수 있는 가장 효과적인 방법이다.

일관성을 지킬시 얻을 수 있는 장점에 대해 설명하고 있습니다. 만약 일관성이 엄격하게 지켜지도록 설계를 하였다면(다형성을 이용해서 설계했다면) 부모 계층에 존재하는 클래스들을 반드시 구현해야 하며 이를 구현하지 않고 코드를 구현하는 것이 더 어렵다는 말입니다. 또한 시스템이 일관성 있는 몇개의 협력 패턴으로 구성된다면 시스템을 이해하고, 수정하고, 확장하는 데 필요한 노력과 시간을 아낄 수 있습니다.

 

협력 패턴에 맞추기

비록 설계를 약간 비트는 것이 조금은 이상한 구조를 낳더라도 전체적인 일관성을 유지할 수 있는 설꼐를 선택하는 것이 현명하다.
...
지속적으로 개선하라
협력은 고정된 것이 아니다. 만약 현재의 협력 패턴이 변경의 무게를 지탱하기 어렵다면 변경을 수용할 수 있는 렵력 패턴을 향해 과감하게 리팩터링하라. 요구상의 변경에 따라 협력 역시 지속적으로 개선해야 한다. 중요한 것은 현재의 설계에 맹목적으로 일관성을 맞추는 것이 아니라 달라지는 변경의 방향에 맞춰 지속적으로 코드를 개선하려는 의지다.

협력패턴(디자인 패턴)과 일관성이 서로 다른 방향을 가리키고 있다면 일관성이 패턴보다 더 우위에 존재한다는 이야기입니다. 처음 해당 챕터를 볼 때에는 그러려니 했지만 포스팅을 하며 다시 14장을 전체적으로 보니 디자인 패턴 혹은 협력 패턴은 어디까지 일관성을 위한 도구일 뿐이라는 느낌을 받았습니다. 그리고 이러한 맥락에서 본다면 목적(일관성)이 방법(디자인 패턴)보다 더 중요하다는 것은 당연한 이야기라 생각합니다.