루비로 배우는 객체지향 디자인 - 1~2장

3장 - 의존성 관리하기

• 잘 디자인된 객체는 하나의 책임만 지고 있기 때문에 객체가 복잡한 작업을 수행하기 위해서 다른 객체와 혀법하지 않을 수 없다.
  • 이 협업은 매우 강력하지만 동시에 위험하다. 협업을 위해 다른 객체에 대한 지식이 있어야 하기 때문이다.
  • 그 지식은 의존성을 만들어낸다.
• 객체는 다음과 같은 내용을 알고 있을 때 의존성을 갖는다.
  • 다른 클래스의 이름
  • 자기 자신을 제외한 다른 객체에게 전송할 메세지의 이름
  • 메세지가 필요로 하는 인자들
  • 인자를 전달하는 순서
• 위의 의존성을 하나의 객체가 변경될 때 어쩔 수 없이 다른 객체도 수정되어야 한다는 것을 의미한다. 이 의존성이 불필요하다면, 코드가 덜 적절해진다.
• 둘 이상의 객체가 강하게 결합되어 있을 때 이들은 한 덩어리로 움직이고 별도로 재사용하는 것이 불가능해진다. 그러니 약하게 결합된 코드를 작성해보자.

// 지난 시간의 Gear 클래스
class Gear {
  constructor(chainring, cog, rim, tire) {
    this.chainring = chainring;
    this.cog = cog;
    this.rim = rim;
    this.tire = tire;
  }

  get gearInches() {
    return this.ratio * new Wheel(rim, tire).diameter;
  }

  // ...
}

new Gear(52, 11, 26, 1.5).gearInches;

• 겉으로 보기에 별 문제 없어보이지만 Gear 가 Wheel 에게 말을 걸려면 일단 Wheel 클래스의 인스턴스를 만들어야 한다. 변경 사항이 발생하면 Wheel 을 다른 것으로 바꾸기만 하면 될까?
  • 위의 코드는 Gear 가 Wheel 외의 다른 객체와 협업하기를 거부하고 있는 것이다.
• 위의 코드는 고정된 타입에 불필요하게 들러붙어 있는 클래스에 얼마나 문제가 많은지 보여준다. 중요한 것은 '객체의 클래스가 무엇인지' 가 아니라 '우리가 전송하는 메세지가 무엇인지' 이다.

class Gear {
  constructor(chainring, cog, wheel) {
    this.chainring = chainring;
    this.cog = cog;
    this.wheel = wheel // 어느 클래스의 인스턴스인지는 Gear가 알바 아니다.
  }

  get gearInches() {
    return this.ratio * this.wheel.diameter
  }

  // ...
}

new Gear(52, 11, new Wheel(26, 1.5)).gearInches;

• 이렇게 수정한 덕분에 Gear 는 diameter 를 구현하고 있는 어떤 객체와도 협업할 수 있게 되었다.
• 불필요한 의존성을 이렇게 제거할 수 없는 경우라면 클래스 안에 격리시켜 놓아야 한다.
  • constructor 안에서 의존성 있는 클래스의 인스턴스를 생성하거나
  • 명시적으로 정의된 메서드를 통해 의존성 있는 클래스의 인스턴스를 만들 수 있다.

class Gear {
  constructor(chainring, cog, rim, tire) {
    this.chainring = chainring;
    this.cog = cog;
    this.wheel = Wheel.new(rim,tire)
  }

  get gearInches() {
    return this.ratio * this.wheel.diameter
  }

  // ...
}

class Gear {
  constructor(chainring, cog, rim, tire) {
    this.chainring = chainring;
    this.cog = cog;
    this.rim = rim
    this.tire = tire
  }

  get gearInches() {
    return this.ratio * this.getWheel().diameter
  }

  getWheel() {
    return this.wheel || new Wheel(this.rim, this.tire)
  }

  // ...
}

• 의존성을 오히려 감추기보다 뚜렷하게 드러내어 재사용이 수월하고, 리팩터링이 가능한 상황일 때 쉽게 수정할 수 있도록 만들었다. 코드가 좀 더 유연해졌고 미래의 변화에 더 쉽게 적응할 수 있도록 해 준 것이다.
• 의존성을 주입하는 코딩 습관을 들일 때 클래스는 자연스럽게 덜 결합된 형태를 띈다. 이런 클래스는 새로운 요구사항을 받아들이기 쉽다.
• 그런데 만약 gearInches 메서드가 더 복잡해지면?

get gearInches() {
  // 무시무시한 수학 공식 몇 줄
  const foo = someIntermediateResult * this.wheel.diameter;
  // 무시무시한 수학 공식 추가
}

• this.wheel.diameter 는 복잡한 다른 연산에 의해 묻혀버렸는데, 결국 this.wheel 은 외부에 대한 의존을 표현하고 있기 때문에 gearInches 를 변화에 취약하게 만들고 있다. 그 와중에 내부가 복잡하다.
• 이럴 때 외부의 의존성을 내부의 메서드로 캡슐화하여 변화에 대한 부담을 완화할 수 있다.

get gearInches() {
  // 무시무시한 수학 공식 몇 줄
  const foo = someIntermediateResult * this._getDiameter();
  // 무시무시한 수학 공식 추가
}

_getDiameter() {
  return this.wheel.diameter;
}