[루비로 배우는 객체지향 디자인] 05. 오리 타입으로 비용 줄이기

• 객체지향 디자인의 핵심에는 메시지가 있다. 메시지는 퍼블릭 인터페이스를 따라 객체들 사이를 오간다. 오리 타입은 이 퍼블릭 인터페이스를 클래스로부터 분리해낸다. 그리고 객체가 누군인지가 아니라 객체가 무엇을 하는지에 따라 가상의 타입을 만들어 낸다.
• 오리 타입은 추상화를 발견할 수 있게 해준다. 이 추상화에 의존할 때 애플리케이션의 위험성은 줄어들고 유연성은 증가한다. 유지보수 비용이 줄어들고 쉽게 수정할 수 있게 된다.
• 오리 타입을 찾아내고 오리 타입의 특성을 최대한 발휘해 애플리케이션을 더욱 유연하고 수정하기 쉽도록 만드는 방법을 설명

오리 타입 이해

• 오리 타입

  • 오리처럼 걷고, 헤엄치고, 꽥꽥 소리를 내면, 그것은 오리일 것이다.

    • 객체의 타입보다는 특성에 초첨을 맞춘다 -> 객체의 속성을 통해서 타입을 판단함.
    • 특정 인터페이스를 구현하고 있지 않아도, 해당 인터페이스에서 요구하는 메서드와 속성을 가지고 있으면 그 인터페이스의 인스턴스로 간주하는 것
    • 개체지향 디자인에서 다형성을 활용하여 코드를 유연하게 작성하는 데에 사용된다.

  • 특정 클래스에 종속되지 않은 퍼블릭 인터페이스

    • 클래스는 객체가 퍼블릭 인터페이스를 갖추기 위한 하나의 수단일 뿐이다.
    • 진짜 중요한 것은 객체가 무엇인가가 아니라 어떻게 행동하는가이다.

  • 최대한 의도를 가지고 구축해야 한다.

    • 해독할 수 없는 혼란으로 가득한 끔찍한 디자인을 만들어낼 수도 있다.
    • 오리 타입은 명시적이고 잘 정리된 계약서와 같은 퍼블릭 인터페이스를 가지고 있어야 한다.

• 오리 타입 찾기

  • 아래 코드의 문제점

    • 아래 메서드는 세 개의 서로 다른 클래스를 참조하고 있고 각 클래스가 구현하고 있는 메서드의 이름을 정확히 알고 있다. -> 의존성!
    • 프로그래머가 애플리케이션에 어떤 클래스가 있는지 잘 모르고 중요한 메시지를 파악하지 못했을 때 이런 코드가 나온다.

    • 이런 코딩 스타일은 재생산 되기 쉬움

      • 여행을 준비하는 또 다른 준비객체가 필요해진다면 이 switch구문에 새로운 case를 추가하게 됨. -> 코드의 변경

    • prepare 메서드 내의 의존성을 제거하기 위해서 prepare 가 무엇을 원하는지에 집중해야 함.

      class Trip{
      prepare(prepareers) {
      preparers.forEach( preparer => {
      switch(typeof preparer){
      	case Mechanic : 
      		preparer.prepareBicycle();
      		break;
      	case TripCoordinator : 
      		preparer.buyFood();
      		break;
      	case Driver : 
      		preparer.gasUp();
      		break;
      	...
      }
      })
      }
      }

  • 오리 타입을 사용해서 얻을 수 있는 이점

    • 오리 타입 코드는 보다 추상적이다. 코드를 이해하기 위해 좀 더 노력해야 하지만, 대신 손쉬운 확장성을 제공한다.
    • 객체지향 디자인은 구체적인 코드를 작성하는 비용 그리고 추상적인 코드를 작성하는 비용 사이의 긴장에서 결코 자유로울 수 없다.
    • 구체적인 코드는 이해하기 쉽지만 확장비용이 높다. 추상적인 코드는 처음에는 불명확해 보이지만 한번 이해하고 나면 수정하기가 쉽다.

  • 다형성 (polymorphism)

    • 같은 타입 또는 인터페이스를 구현하는 여러 객체가 동일한 메서드 호출로 다른 동작을 할 수 있도록 하는 것을 의미
    • 하나의 메서드 시그니처에 다른 동작 -> 코드의 재사용성과 유연성을 높일 수 있도록 한다.
    • 메시지의 송신자는 수신자의 클래스를 신경 쓸 필요가 없다. 수신자는 주어진 행동에 걸맞는 자신만의 행동을 제공한다.

오리 타입 사용 시그널

• 오리 타입을 사용하려면 클래스를 가로지르는 인터페이스를 사용하면 좋은 지점을 찾아내는 안목부터 갖춰야 한다.
• 오리 타입이 필요하다는 사실을 인지하고 인터페이스를 추상화 시키기

• 숨겨진 오리 타입 찾기

  • 클래스에 따라 변경되는 case 구분 -> 위의 코드 처럼!

    • 협업하는 객체에 대한 믿음이 부족하다는 사실을 말해주는 코드. 코드를 수정하기 어렵게 만드는 의존성을 불러온다.
  • kindOf, isA
• 디자인의 목표는 비용을 줄이는 것이다. 모든 상황에 이 기준을 적용해야 한다. 오리 타입을 만들어서 불안정한 의존성을 줄일 수 있다면, 만들면 된다. 잘 생각해서 판단하도록 하자.

동적 타입, 정적 타입

• 책에서는 정적 타입의 이전들에서 얘기하지만 개발 고렙일 때 가능한 일들 같다...ㅎ

• 정적 타입의 장단점

  • 장점

    • 컴파일 시간에 타입 오류를 잡을 수 있다. 그러나 타입 변형을 사용하는 순간 모든 확신은 사라진다.
    • 코드 자동 완성 및 IDE 지원이 좋다.
    • 코드 가독성이 높아진다.
    • 성능이 좋아진다.

  • 단점

    • 개발자가 코드 작성 시간에 더 많은 코드를 작성해야 한다.
    • 초기 학습 비용이 높다.
    • 코드 유연성이 떨어질 수 있다

• 동적 타입의 장단점

  • 장점

    • 더 적은 코드로 작성할 수 있다.
    • 빠르게 프로토타입을 만들 수 있다.
    • 더 높은 코드 유연성을 제공한다.

  • 단점

    • 런타임 오류가 발생할 가능성이 높다.
    • 코드 작성 시간에 타입 오류를 찾을 수 없다.
    • IDE 지원이 좋지 않을 수 있다.

• 오리 타입과 인터페이스의 차이

  • 덕타이핑과 인터페이스는 모두 주어진 객체가 준수해야 하는 동작을 정의하는 방식
  • 주요 차이점은 적용하는 방식에 있다.
  • 덕 타이핑 : 동적으로 타입이 지정된 언어에서 유연성과 사용 편의성을 제공하는 런타임 개념
  • 인터페이스 : 정적으로 타입이 지정된 언어에서 타입 안전성과 계약의 엄격한 적용을 가능하게 하는 컴파일 타임 개념.