더북(TheBook)

물론 빌리는 객체는 빌려주는 객체의 질문에 반드시 대답해야 한다.


MyApp.Gorilla.prototype.getHandCount = function() {
return this.hands.length;
};

이제 사람이 고릴라에게 수화 능력을 재능 기부할 차례다.

trainer.endowSigning(koko);

 

이런 식으로 한 객체의 기능 다발 전체를 다른 객체로 패치할 수도 있다. 정통 개발자들은 이 기능 다발이 곧 인터페이스 구현체가 아닌가 싶을 텐데, 인터페이스뿐만 아니라 코드도 함께 구현한 터라 사실 다중 상속(multiple inheritance)에 더 가깝다!

멍키 패칭은 ‘메서드 빌림(method borrowing)’이라는 그럴싸한 타이틀로 19장에서 한 번 더 자세히 설명한다.

▼ 표 3-7 멍키 패칭의 SOLID/DRY 요약표

원칙

결과

단일 책임

기증받은 기능 다발이 단일 책임으로 이루어진다 해도 빌림 자체로 빌리는 객체에 책임을 전가하는 게 아닌가 하는 점에서 논란의 여지는 있을 수 있다. 하지만 그런 식으로 생각하면 애스팩트 역시 책임을 더하는 건 마찬가지라서 결국 어불성설이다.

개방/폐쇄

멍키 패칭을 분별 있게 잘 쓰면 개방/폐쇄 원칙을 어길 일은 없다.

리스코프 치환

빌린 함수가 새 집과 옛집에서 그 의미가 같다면 문제없다.

인터페이스 분리

인터페이스 분리 원칙은 멍키 패칭이 추구하는 바로 그 자체다!

의존성 역전

의존성은 보통 빌려주는 객체 또는 빌리는 객체 어느 쪽에도 주입될 수 있다.

DRY(반복하지 마라)

창의적이고 책임감 있는 개발자의 손을 거친다면 멍키 패칭은 DRY한 코드를 유지하는 데 도움이 많이 될 것이다.

신간 소식 구독하기
뉴스레터에 가입하시고 이메일로 신간 소식을 받아 보세요.