Ch.14 일관성 있는 협력

일관성 있는 협력을 위한 지침

  1. 변하는 개념을 변하지 않는 개념으로부터 분리하라.

  2. 변하는 개념을 캡슐화하라.

유사한 기능에 대해 서로 다른 방식으로 구현하지 말자.

  1. 코드의 일관성이 깨지게 된다.

  2. 서로 다른 구현 방식은 코드를 이해하는 데 방해된다.

유사한 기능은 유사한 방식으로 구현해야 한다.

다시 말하지만 코드 재사용을 위한 상속은 해롭다.

유사한 기능에 대해 유사한 협력 패턴을 적용하자.

직관적으로 코드를 이해할 수 있게 되고, 다음에 같은 패턴을 이용해 설계할 수 있게 된다.

그런데 이렇게 계속 일관성을 유지하도록 코드를 짜다가도 새로운 요구사항이 생기면서 일관성의 벽에 조금씩 금이 가게 된다.

협력 설계 초기 단계에서 모든 요구사항을 예측하는 것이 불가능하기 때문에 자연스러운 현상이며, 오히려 새로운 요구사항을 수용할 수 있는 협력 패턴을 향해 설계를 진화시킬 수 있는 좋은 신호이다.

가장 중요한 것은 현재의 설계에 맹목적으로 일관성을 맞추는 게 아니라 달라지는 변경의 방향에 맞춰 지속적으로 코드를 개선하려는 의지이다.

INFORMATION EXPERT PATTERN

  • 어떤 책임에 대한 정보를 가장 잘 아는 객체에게 그 책임을 할당하자.

변경을 캡슐화하자

캡슐화란 변하는 어떤 것이든 감추는 것이다.

  • 변하는 부분과 변하지 않는 부분을 구분하고 분리하자.

    • 변하는 부분을 적절히 추상화하자.

    • 변하지 않는 부분을 이용해 객체 간의 협력을 설계하자. 이것이 재사용 가능한 협력 패턴이 된다.

객체지향에서 변경을 다루는 전통적인 방법은 조건 로직을 객체 사이의 이동으로 바꾸는 것이다.

협력이 잘 될지 안될지 아는 가장 쉬운 방법은 구현해보는 것이다.

설계에 일관성 부여하기

  1. 일관성 있는 설계를 만들기 위해 다양한 설계 경험을 익히자.

  2. 널리 알려진 디자인 패턴을 학습하고, 변경이라는 문맥 안에서 디자인 패턴을 적용해보자.

패턴을 찾아라

일관성 있는 협력의 핵심은 변경을 분리하고 캡슐화하는 것이다.

  • 애플리케이션에서 유사한 기능에 대한 변경이 지속적으로 발생하고 있다면 변경을 캡슐화할 수 있는 적절한 추상화를 찾은 후, 이 추상화에 변하지 않는 공통적인 책임을 할당하라.

  • 현재의 구조가 변경을 캡슐화하기 적합하지 않다면 코드를 수정하지 않고도 원하는 변경을 수용할 수 있도록 협력과 코드를 리팩터링하라.

정리

위에서 나온 내용과 더불어, 설계는 고정된 것이 아니라 요구사항의 변경에 따라 유동적으로 변화하며, 계속 수정해나가는 과정 속에서 다듬어진다는 점에 유의하는 것이 좋겠다.

기타 참고

  • Tecoble - 원시 타입을 포장해야 하는 이유

    • 여기서는 로또 숫자를 관리하는 데 있어 primitive type int가 아닌 LottoNumber로 wrapping하여, 그걸 다시 Lotto로 wrapping하고 있다. (밑의 일급 컬렉션 참고.) 이렇게 함으로써,

      • 객체 스스로 자신의 상태를 관리할 수 있다.

      • 코드의 유지보수에 용이하다.

      • 자료형에 구애받지 않는다.

  • Tecoble - 일급 컬렉션을 사용하는 이유

    • 일급 컬렉션 - Collection을 wrapping하면서 wrapping한 Collection 외 다른 멤버 변수가 없는 상태.

    • 상태와 로직을 따로 관리하여 로직이 사용되는 클래스의 부담을 줄이고 중복 코드를 줄일 수 있다.

Last updated