🌈 Chapter 6: 객체 지향 스타일

📚 유지 보수성을 고려한 설계

• 코드 규모가 커질 경우 해당 코드를 계속해서 이해하고 유지 보수할 수 있는 방법은 기능을 객체로, 객체를 패키지로, 패키지를 프로그램으로, 프로그램을 시스템으로 구조화하는 것밖에 없다.

🐶 관심사의 분리

• 시스템 동작 방식을 변경해야 할 경우, 우리는 되도록 적은 양의 코드를 변경하고자 한다. 관련된 변경 사항이 전부 코드의 어느 한군데에 들어 있다면 작업을 완료하고자 시스템 여러 곳을 변경하지 않아도 된다. 그러나 시스템에서 어느 부분을 변경해야 할지 예측하지 못하므로 같은 이유로 변경해야 할 코드는 한데 모은다.

🐶 더 높은 수준의 추상화

• 더 높은 수준의 추상화를 활용해 복잡성을 피한다.
• 변수와 제어 흐름을 조작하기보다는 유용한 기능 컴포넌트를 조합하는 식으로 프로그램을 작성하면 더 많은 일을 해낼 수 있다.
• 위 두 가지를 일관되게 적용하면 애플리케이션 구조가 콕번의 포트와 어댑터 아키텍처 같은 것으로 나아갈 것이다. 여기서 포트와 어댑터란 비즈니스 도메인의 코드가 데이터베이스나 사용자 인터페이스 같은 기술 기반 구조의 의존성과 격리된 아키텍처를 의미한다.
• 코드를 깔끔하게 분리할 수 있게끔 인터페이스를 놓을 동작 방식상의 접점을 어떻게 찾을까?
  • 캡슐화: 서로 관련이 없는 컴포넌트 간에 예상치 못한 의존성이 없음을 보장함으로써 한 객체에 대한 변경사항이 시스팀의 다른 부분에 얼마나 영향을 줄지 통제할 수 있다. 객체의 행위가 해당 객체의 API를 통해서만 좌우될 수 있음을 보장한다.
  • 정보 은닉: 객체가 해당 객체의 기능을 구현하는 방법을 추상화된 API 너머로 감춘다. 정보 은닉을 통해 당면한 과제와 관련이 없는 낮은 수준의 세부 사항을 알 필요 없이 더 높은 수준의 추상화를 활용할 수 있다.

📚 내부 대 이웃

• 시스템을 구성할 때는 각 객체의 안팎으로 무엇을 둘지 결정해 해당 객체가 명확한 API와 함께 응집력 있는 추상화를 제공하게 해야 한다.
• 객체에서 중요한 것은 API를 통해 해당 객체의 내부에 접근하는 것을 캡슐화하고, 세부 사항을 시스팀의 나머지 부분으로부터 감추는 것이다. 시스템에서 한 객체는 다른 객체와 메시지를 주고받으며 의사소통한다. 한 객체와 직접 의사소통하는 객체를 해당 객체의 이웃(peer)라고 한다.
• API를 통해 객체 내부 구조를 너무 많이 노출하면 클라이언트에서는 해당 API를 얼마간 업무에 활용할 것이고 객체의 동작 방식이 너무 많은 객체에 널리 퍼질 테고 결합도가 높아질 것이며 이제 무엇을 변경하든 코드 전체에 그러한 변경 사항의 효과가 퍼져 유지 보수 비용이 증가할 것이다.

📚 단일 책임 원칙

• 모든 객체는 반드시 단 한 가지 명확히 규정된 책임을 지녀야 한다.
• 어떤 객체의 역할을 설명하는 데 절을 집어넣는다면 아마 해당 객체는 보통 각 절마다 하나씩 여러 개의 협력 객체로 나뉠 것이다.

📚 객체 이웃의 유형

• 우리는 이웃하는 객체와의 관계를 대략 세 가지 유형으로 나눈다. 한 객체가 지닐 수 있는 관계는 다음과 같다.

🐶 의존성

• 한 객체가 자신의 역할을 수행할 수 있게 이웃하는 객체에게 요구하는 서비스다.
• 해당 객체는 이 서비스 없이는 기능을 수행하지 못하며, 객체 자체를 생성할 수 없을 것이다.

🐶 알림

• 한 객체의 최근 활동을 지속적으로 파악하는 이웃이다. 해당 객체는 상태가 바뀌거나 중요한 활동을 수행할 때마다 특정 이웃에게 이러한 사실을 알린다.
• 객체는 어떤 이웃이 자신에게 귀를 기울이고 있는지 모르거나 신경 쓰지 않는다. 알림이 유용한 까닭은 객체를 서로 분리해주기 때문이다.

🐶 조정

• 객체의 행위를 더 넓은 시스템의 요건에 맞게 조정하는 이웃이다. 여기에는 해당 객체를 대신해 의사 결정을 내리는 정책 객체와 객체가 복합체인 경우 해당 객체의 컴포넌트 부분이 포함된다.

🐶 정리

• 이러한 객체 이숭의 유형은 설계와 관련된 고민에 도움을 주는 휴리스틱에 불과할뿐 반드시 지켜야 할 법칙은 아니다. 무엇보다 중요한 것은 바로 협력 객체가 사용되는 맥락이다.

📚 전체는 부분의 합보다 단순해야 한다

• 복합 객체의 API는 반드시 구성 요소의 존재와 구성 요소 간의 상호 작용을 감추고 더 단순한 추상화를 이웃에게 드러내야 한다.

// 하위 컴포넌트를 직접 제어
moneyEditor.getAmountField().setText(String.valueOf(money.amount()));
moneyEditor.getCurrencyField().setText(money.currencyCode());
// 여전히 내부 구조가 드러난다.
moneyEditor.setAmountField(money.amount());
moneyEditor.setCurrencyField(money.currencyCode());
// 명시적으로 컴포넌트를 관리
moneyEditor.setValue(money);

• 코드 규모가 커짐에 따라 전체는 부분의 합보다 단순해야 한다는 규칙이 추상화 수준을 높이는 데 이바지할 것이다.

📚 콘텍스트 독립성

• 콘텍스트 독립성은 한 객체가 정보를 너무 많이 감췄거나 잘못된 정보를 감췄는지 판단하는 데 유용하다.
• 시스템을 구성하는 객체가 콘텍스트 독립적이라면 해당 시스템은 변경하기가 쉽다. 여기서 콘텍스트 독립적이라는 말은 각 객체가 해당 객체를 실행하는 시스템에 관해 아무것도 알지 못한다는 것이다.
• 콘텍스트 톡립적이려면 어떤 객체가 실행되고 있는, 규모가 더 큰 환경에 대해 해당 객체가 알아야 할 사항을 전부 전달해야 한다.
• 이처럼 가부장적인 접근법에서는 각 객체는 자기 역할을 수행하는 데 필요한 만큼 정보를 전달받고 그러한 역할 표현과 부합하는 추상화에 포함된다. 결국 객체 사슬이 프로세스 경계, 즉 시스템이 호스트 이름이나 포트, 사용자 인터페이스 이벤트 같은 외부적인 세부 사항을 발견하게 되는 곳까지 이르게 된다.
• 여러 객체로 구성된 시스템에서 콘텍스트 독립성 규칙의 효과는 객체의 관계를 명시적으로 만들고 객체 자체와는 별도로 정의되게 만든다. 이렇게 되면 객체가 단순해지는데, 객체가 자신의 관계를 직접 관리하지 않아도 되기 때문이다.
• 콘텍스트 독립성을 따르면 다양한 콘텍스트에 적용할 수 있는 응집력 있는 객체를 만들 수 있고 객체 구성 방법을 재설정해서 변경 가능한 시스템으로 나아갈 수 있다.

📚 올바른 정보 감추기

• 캡슐화는 거의 늘 하면 좋긴 하지만 때로는 정보를 잘못된 곳에 감추는 일이 생길 수 있다. 그러면 코드를 이해하거나 통합하기가 힘들어지고, 객체를 구성하는 식으로 행위를 만들어내기도 어려워진다.
• 이를 방지하는 가장 좋은 방법은 설계 논의 시 두 가지 개념의 차이점을 분명하게 인식해야 한다. 이를테면, 다음과 같이 말하기도 한다.

• 캐시에 대한 자료 구조를 CachingAuctionLoader 클래스에 캡슐화한다.
• 애플리케이션 로그 파일의 이름을 PricingPolicy 클래스에 캡슐화한다.

• 앞 문장은 다음과 같이 정보 은닉 측면에서 문장을 재구성하기 전까지는 틀린 구석이 없어 보인다.

• 캐시에 사용되는 자료 구조를 CachingAuctionLoader 클래스에 감춘다.
• 애플리케이션 로그 파일의 이름을 PricingPolicy 클래스에 감춘다.

• 콘텍스트 독립성은 로그 파일의 세부 사항을 PricingPolicy 클래스에 감추는 업무가 없음을 보여준다. 로그 파일 이름이 필요하다면 그것은 외부 환경 설정을 처리하는 수준에 포함되고 그곳에서 전댈돼야 한다.