Joe Armstrong의 바나나 원숭이 정글 문제를 설명하는 샘플 코드

책에서 직장에서 코더 조 암스트롱 밝혔다 :

재사용 성 부족은 기능적 언어가 아닌 객체 지향 언어에서 비롯된 것 같습니다. 객체 지향 언어의 문제는 그들이 가지고 다니는 모든 암시 적 환경을 가지고 있다는 것입니다. 바나나를 원했지만 바나나와 정글 전체를 들고있는 고릴라

나는 여기에 그것을 얻지 못한다. 문제가 바나나를 얻는 것이라면 'getBanana'함수 뒤에있는 모든 논리를 캡슐화 할 수 있습니다. 이 맥락에서 원숭이와 정글은 어떻게 관련되어 있습니까? 누군가의 쓰기 방법을 이해하기 쉽게에서 문제를 설명하는 코드 수, 말은 사실 증명 Banana개체가를 필요로 Monkey하고 Jungle, 제발 시작하는 객체를?

그는 실제 OOP 프로그램의 대다수가 우려의 분리를 존중하지 않는다는 사실을 암시하고있다. 예를 들어 다음과 같은 클래스를 가질 수 있습니다.

public class Banana
{
    public Monkey Owner {get;}
}

public class Monkey
{
    public Jungle Habitat {get;}
}

public class Jungle
{
}

당신이 사용하는 경우 Banana, 또한에 의존 이적으로 필요 Monkey하고 Jungle.

그러나 나는 이것이 OOP의 문제이며 기능적 스타일에 어쨌든 가지고 있지 않다는 것에 완전히 동의하지 않습니다. 이것은 올바른 추상화를 도입하여 OOP에서 쉽게 고칠 수 있습니다.

문제는 관심사 분리를 신경 쓰지 않는 개발자에 관한 것입니다. 그리고 OOP 프로그래머 대부분이 초보자라고 주장하는 것을 두려워하지 않을 것입니다. 기능적 프로그래머에게는 약간의 경험이 있으며 코드를 올바르게 분리하도록 동기를 부여합니다.

가능한 추상화는 다음과 같습니다.

public class Banana
{
    public IBananaOwner Owner {get;}
}

public interface IBananaOwner
{
}

public class Monkey : IBananaOwner
{
    public Jungle Habitat {get;}
}

public class Jungle
{
}

이렇게하면 Banana소유자가 있다는 것을 알 수 있지만 반드시 그럴 필요는 없습니다 Monkey. 무엇이든 될 수 있습니다. 또한 Banana소유자가 수행 할 수 있는 작업을로 정의 된 작업으로 만 제한하므로 IBananaOwner추론이 간단 해집니다.

고릴라는 원숭이가 아닙니다!

이를 제쳐두고 " getBanana " 함수 뒤에있는 모든 논리를 캡슐화 할 수 있습니다 . 내가 원하는 것은 바나나이지만, 그것을 얻으려면 클래스 getBanana의 인스턴스와 같은 객체 를 호출해야합니다 Gorilla. 그러면 바나나 개체는 자신이 속한 고릴라에 대한 참조를 포함하고 그 고릴라 개체는 그에 속한 숲에 대한 참조를 갖게됩니다. 그래서 나는 바나나를 요구하지만 그 뒤에는 정글 전체가 캡슐화되어 있습니다.

극단적 인 예이며 항상 그렇게 나쁘지는 않습니다. 그러나 이와 같은 OO 시스템으로 끝나는 것은 드문 일이 아닙니다. 따라서이 getBanana방법 을 테스트 하려면 전체 포리스트를 인스턴스화하거나 조롱해야합니다.