🌈 Chapter 7: 객체 지향 설계의 달성

📚 테스트를 먼저 작성하는 것이 설계에 어떻게 도움이 되는가

• 객체가 해당 객체를 둘러싼 더 큰 환경과 조화되는 응집력 있는 단위를 나타내기를 바란다. 그러한 컴포넌트로 만들어진 시스템은 요구 사항이 변경될 때 재구성과 적응에 필요한 유연함을 갖출 것이다.
• 이 같은 관찰에 도움이 되는 TDD의 세 가지 측면이 있다.
  1. 테스트로 시작한다는 것은 어떻게를 고려하기 전에 달성하고자 하는 바가 무엇인지를 기술해야 함을 의미한다. 이는 대상 객체에 대해 추상화를 올바른 수준으로 유지하는 데 기여한다.
  2. 단위 테스트를 이해 가능한 상태로 유지하려면 단위 테스트의 범위를 제한해야 한다.
  3. 단위 테스트를 위한 객체를 만들려면 해당 객체의 의존성을 전달해야 하는데, 이는 그러한 의존성이 어디에 있는지 알아야 한다는 의미다. 그러면 콘텍스트 독립성이 높아지는데, 이것은 단위 테스트를 수행하기에 앞서 대상 객체의 환경을 구성할 수 있어야 하기 때문이다.

📚 분류보다 의사소통

• 목 객체를 활용한 TDD는 정보 은닉을 촉진한다. 목 객체는 객체 내부에 존재하는 것이 아니라 객체의 동적 요소(peer), 즉 해당 객체의 의존성, 알림, 조정을 대상으로 만들어야 한다.
• 한 객체의 인접 요소를 강조하는 테스트는 그것들이 이웃 요소인지, 그리고 이웃 요소가 아니라면 그것들이 대상 객체의 내부를 구성해야 하는지 파악하는 데 기여한다.

📚 값 타입

• 값 타입을 도입할 때 세 가지 기본적인 기법을 활용하는데, 바로 분해, 파생, 포장이 여기에 해당한다.

🐶 분헤(breaking out)

• 어떤 객체의 코드가 복잡해지고 있다면 그것은 해당 코드가 다수의 관심사를 구현하고 있으니 이를 응집력 있는 행위의 단위로 분해해 도움이 타입으로 만들어내라는 신호로 볼 수 있다.

🐶 파생(budding off)

• 코드에서 새로운 도메인 개념을 표기하고 싶을 때 필드 하나만 있거나 필드가 아무것도 없는 위치지정자 타입을 도입한다. 코드의 규모가 커짐에 따라 필드와 메서드를 추가해 새로운 타입의 세부 사항으로 채우고 추가한 각 타입을 이용해 코드 추상화 수준을 높인다.

🐶 포장(bundling up)

• 늘 함께 취급되는 공용 필드가 포함된 타입을 새로 만든다. 나중에 새 타입으로 행위를 옮길 수도 있는데, 이것은 결국 새 타입에 포함된 필드를 깔끔한 인터페이스 너머로 감추게 해줘서 전체는 부분의 합보다 단순해야 한다라는 규칙을 만족시킬 것이다.

📚 객체는 어디에서 오는가?

🎈 분해: 큰 객체를 협력 객체의 그룹으로 나누기

• 응집력 있는 기능 단위를 좀 더 작은 협력 객체로 만드는 작업을 시작한다. 그렇게 하고 나면 독립적으로 단위 테스트를 할 수 있다. 아울러 새 객체로 나누는 과정에서 끄집어 내려는 코드의 의존성을 살펴볼 수밖에 없다.
• 정리 작업을 지연하는 것과 관련해서는 두 가지 우려가 있다.
  1. 뭔가를 하기 전까지 얼마나 기다려야 하는가다. 너무 많은 코드가 의도가 불분명해서 팀이 감당할 수 없을 때 정리 비용을 치러야 하는 상황까지 올 수 있다.
  2. 이러한 코드를 시험용 코드로 여기는 게 나을 때도 있다는 것이다. 즉, 일단 어떻게 해야 할지 알면 원래대로 돌린 다음 깔끔하게 다시 구현하는 편이 낫다는 말이다.

🎈 파생: 객체가 필요로 하는 신규 서비스 정의와 해당 서비스를 제공하기 위한 새 객체 추가

• 코드가 좀 더 안정화되고 어느 정도 구조를 갖추고 나면 새로운 타입을 현실적으로 끄집어내는 식으로 그것들을 발견한다. 이때 어떤 새로운 기능은 설계 원칙에 속하지 않는다는 사실을 발견할지도 모른다.
• 이러한 경우 인터페이스를 만들어 객체 관점에서 필요한 서비스를 정의한다. 대상 객체와 해당 객체의 협력 객체 간의 관계를 기술하는 데 도움이 되는 목 객체를 이용해 서비스가 이미 존재하는 양 새로운 행위에 대한 테스트를 작성한다.
• 그러고 나서 그 서비스를 제공하는 객체를 작성하는데, 이 과정에서 해당 객체가 필요로 하는 서비스가 뭔지 파악한다. 기존 객체, 또는 자체적으로 만든 API나 서드 파티의 API와 연결하기 전까지 이처럼 협력 객체의 관계로 구성된 흐름을 따른다. 바로 이런 식으로 입력에서 출력 방향으로 개발하라를 구현하는 것이다.
• 이를 주문형 설계라고 생각하는데 즉, 어떤 클래스에서 제공해야 할 기능을 밀어내지 않고 클라이언트의 요구 사항으로부터 인터페이스와 해당 인터페이스의 구현체를 현실로 끄집어내는 것이다.

🎈 포장: 관련 객체를 포함 객체로 감추기

• 이것은 전체는 부분의 합보다 단순해야 한다 규칙의 응용이다. 함께 동작하는 관련 객체의 집합이 있을 경우 그것들을 하나로 포함하는 객체로 포장할 수 있다.
• 새 객체는 기존 집합의 복잡성을 추상화 너머로 감춰서 좀 더 높은 수준에서 프로그램을 작성할 수 있게 해준다.
• 암시적인 개념을 구체적으로 만드는 과정의 다른 좋은 효과
  1. 도메인을 좀 더 잘 이해하는 데 보탬이 되는 이름을 개념에 부여해야 한다.
  2. 개념의 경계를 확인할 수 있으므로 의존성의 범위를 좀 더 명확하게 한정할 수 있다.
  3. 단위 테스트를 좀 더 정확하게 수행할 수 있다.

📚 인터페이스로 관계를 식별하라

• 인터페이스를 사용해 객체가 수행할 수 있는 역할에 이름을 부여하고 객체가 받아들일 메시지를 기술한다.
• 인터페이스에 선언되는 메서드 수가 적을수록 해당 메서드를 호출하는 객체의 역할이 명확해진다. 그러면 특정 호출에 대해 다른 어떤 메서드가 관련이 있는지, 어떤 메서드가 편의를 위해 포함됐는지에 대해 걱정하지 않아도 된다.
• 클라이언트 코드에서 인터페이스를 쓰게 하면 해당 인터페이스의 구현에 관한 불필요한 정보가 새는 현상을 방지할 수 있다. 이로써 객체 간의 암시적인 결합이 최소화되고 코드는 변경하기 쉬운 상태에 머물게 된다.

📚 인터페이스도 리팩터링하라

• 비슷하게 보이는 인터페이스를 분리하기로 했다면 해당 인터페이스의 이름을 재고해 보기에 좋은 시점이다. 이 과정에서 인터페이스 가운데 최소한 하나는 좀 더 적절한 이름을 갖게 될 가능성이 있다.
• 인터페이스 리팩터링을 고려할 또 한 번의 시점은 인터페이스를 구현하기 시작할 때다. 이를테면, 구현하는 클래스의 구조가 불분명하다는 사실을 알게된다면 아마 해당 인터페이스에 책임이 너무 많을 테고, 이는 인터페이스가 너무 장황해서 쪼개야 한다는 힌트일지도 모른다.

📚 객체를 구성해 시스템의 행위를 기술하라

• 테스트는 각 객체가 어떻게 활동해야 하고 다른 객체와 어떻게 결합될 수 있는지 이해하는 데 보탬이 된다. 그러고 나면 저수준 객체를 좀더 기능이 풍부한 기본 구성 요소로 사용할 수 있다. 이것이 바로 객체의 망이다.
• 이 접근법의 좋은 점은 비교적 적은 코드로도 유연한 애플케이션 구조가 만들어진다는 것이다. 특히 코드가 여러 관련 시나리오를 지원해야 할 때 적절한 방법이다. 새로 착탈 가능한 컴포넌트를 작성해 추가하기만 하면 된다.

📚 고수준 프로그래밍을 위한 대비

• 우리는 코드를 두 가지 계층으로 구성한다.
  • 하나는 객체의 그래프에 해당하는 구현 계층(implementation layer)으로 이 계층의 행위는 해당 계층에 속하는 객체가 이벤트에 어떻게 반응하는가로 결정된다.
  • 다른 하나는 구현 계층의 객체를 만들어내는 선언적 계층(declarative layer)으로 자그마한 편의성 메서드와 문법을 이용해 각 부분의 용도를 기술한다.
• 선언적 계층은 코드에서 하려는 일이 무엇인지를 기술하는 반면, 구현 계층에서는 코드가 그것을 어떻게 하는지를 기술한다.
• 구현 계층에서는 관례적인 객체 지향 스타일 지침을 고수하는 반면, 선언적 계층의 경우에는 좀 더 융통성이 있다. 즉, 열차 전복과 같은 메서드 호출 연쇄나 정적 메서드를 사용할 수도 있다는 것이다.

// jMock
context.checking(new Expectations() {{
  oneOf(example).doSomething(with(any(String.class)));
}});

• 결국 목표는 더 적은 코드로 더 많은 일을 해내는 것이다. 스스로가 제어 흐름과 데이터 조작이라는 측면의 프로그래밍에서 더 작은 프로그램을 가지고 프로그램을 구성하는, 즉 객체가 더 작은 행위의 단위를 형성하는 수준에 이르기를 갈구한다.

📚 그럼 클래스는?

• 클래스보다 인터페이스를 강조하는데, 다른 객체에서 보는 것은 결국 인터페이스이기 때문이다. 즉, 객체의 타입은 해당 객체가 수행하는 역할로 규정된다.
• 객체에 대한 클래스를 구현 세부 사항으로 본다. 클래스는 타입을 구현하는 한 방식이지, 타입 자체가 아니다.
• 우리는 공통적인 행위를 추려냄으로써 객체 클래스 계층 구조를 파악하며, 가능하다면 위임으로 리팩터링하는 방식을 선호한다. 이는 위임으로 코드를 더 유연하고 이해하기 쉽게 만들 수 있기 때문이다.