오브젝트: 코드로 이해하는 객체지향 설계 14장을 읽으며

오브젝트: 코드로 이해하는 객체지향 설계 14장을 읽으며

 

느낀점

서비스 발전하면서 계속 코드 수정하게 되는데, 그때는 맞고 지금은 틀리다가 가장 정확한 표현인 것 같다

 

 

일관성 있는 협력

객체는 협력을 위해 존재하며, 협력은 객체가 존재하는 이유와 문맥을 제고

• 잘 설계된 애플리케이션은 이해하기 쉽고, 수정이 용이하며, 재사용 가능합 협력의 모임
• 일관성 있는 패턴을 적용하면 이해하기 쉽고 직관적이며 유연해진다는 것

코드 재사용을 위한 상속은 해롭다

두 클래스 사이의 강한 결합도는 설계 개선과 기능의 추가를 방해

 

설계에 일관성 부여하기

일관성 있는 설계를 만드는데 가장 훌룡한 조언은 다양한 설계 경험을 익히는 것

• 풍부한 설계를 가진 사람은, 그 변경을 어떻게 다뤄야 하는지에 대한 통찰력을 가짐
• 일관성을 제공하기 위해 어떤 방법을 사용해야 하는지를 직관적으로 결정할 수 있음
• 설계 경험을 단기간에 쌓아 올리는 것은 생각보다 어려움

두번째 조언은 디자인 패턴을 학습하고 변경이라는 문맥 안에서 디자인 패턴을 적용해보는 것

• 특정한 변경에 대해 일관성 있는 설계를 만들 수 있는 경험 법칙을 모아놓은 일종의 설계 템플릿
• 반복적으로 적용할 수 있는 설계 궂를 제공한다고 하더라도 모든 경우에 적합한 패턴을 찾을 수 있는 것은 아님

휼룡한 구조를 설계하기 위해 따라야 하는 기본 원칙

• 변하는 개념을 변하지 않는 개념으로부터 분리
• 변하는 개념을 캡슐화

조건 로직 대 객체 탐색

변경 주기가 서로 다른 클래스가 하나에 뭉쳐 있으면 좋지 않으며, 일관성있는 협력을 위한 지침을 따르면 좋음

• 변하는 개념을 변하지 않는 개념으로부터 분리
• 변하는 개념을 캡슐화

상속대신 합성을 이용하거나, 리스코프 치환 원칙을 준수해 계층을 구현하는데 상속 활용

캡슐화 다시 살펴보기

캡슐화에 관한 이야기를 들으면 반사저긍로 데이터 은닉(data hiding)을 떠올림.

• 데이터 은닉이란 오직 외부에 공개된 메서드를 통해서만 객체의 내부에 접근할 수 있게 제한함으로써 객체 내부의 상태 구현을 숨기는 기법
• 객체의 모든 인스턴스는 private으로 선언해야 하고 오직 해당 클래스의 메서드만이 인스턴스 변수에 접근할 수 있어야 함.
• 캡슐화란 변하는 어떤 것이든 감추는 것
  
  • 데이터 캡슐화: 인스턴스를 private으로 만들며, 외부 접근은 오직 메서드에 이용하는 것 뿐
  • 메서드 켑슐화: 상속에서 자식 클래스에 선언된 메서드의 가시성은 protected(자바) 클래스 외부에서는 이 메서드에 직접 접근 불가하지만 서브 클래스에서는 접근 가능. 내부 행동을 캡슐화
  • 객체 캡슐화: 객체와 객체 사이의 관계를 캡슐화
  • 서브타입 캡슐화: 서브타입의 종류를 캡슐화 하는게 다형성의 기반이 됨
• 서브타입 캡슐화를 적용하는 두가지 방법
  • 변하는 부분을 분리해서 타입 계층을 만들기
  • 변하지 않는 부분의 일부로 타입 계층을 합성하기

 

변경 분리하기

일관성 있는 협력을 만들기 위한 첫 단계는 변하는 개념과 변하지 않는 개념을 분리하는 것

• 구현 요구 사항에 따라서 정책을 정리
  • 시간대 및 구견별 금액 > 변하는 부분인 적용 조건
  • 단위 요금 > 변하지 않는 부분인 조건

구체적인 협력 구성하기

규칙을 지키는 것보다 어기는 것이 더 어렵다는 것에 주목

• 개발자에게 확장 포인트를 강제하여 정해진 구조를 우회하게 어렵게 만듦
• 재사용성이 향상되고, 테스트해야 하는 코드의 양이 감소
• 유사한 기능에 대해 유사한 협력 패턴을 작성하는 것을 객체 지향 시스템에서 개념적 무결성(Conceptual Integrity)라고 함

 

지속적으로 개선하라

처음에는 일관성을 유지하는 것처럼 보이던 협력 패턴이 시간이 흐르면서 새로운 요구사항이 추가되는 과정에서 일관성의 벽에 조금씩 금이 가는 경우를 자주 봄. 초기 단계에서 모든 요구사항을 미리 예상할 수 없기 때문에 자연스러운 현상

• 협력은 고정되는 것이 아님.
• 현재 협력 패턴이 변경의 무게를 지태하기 어렵다면 변경을 수용할 수 있는 협력 패턴을 향하 과감하게 라팩토링 진행
• 요구사항의 변경에 따라 협력 역시 지속적으로 개선해야 함.
• 중요한 것은 현재의 설계에 맹목적으로 일관성을 맞추는 것이 아니라 달라지는 변경의 방향에 맞춰 지속적으로 코드를 개선하려는 의지