만화에서 알 수 있는 Abstract Factory

누군가 만들어 주는 사람이 있는 것으로 하고, 놀이 쪽에 의식이 가 버리고 있네요. 좋네요, 이것이야말로 객체 지향의 묘미입니다.

복잡한 것을 가능한 한 간단하게 만들려면 "관심 분리"가 중요합니다. 특히 조작에 대한 지식과 생성에 대한 지식을 분리하는 것이 좋은 아이디어입니다. 조작할 때마다, 어떤 제작인지를 신경쓰고 if - else를 써 버리면, 「라디콘의 프로포를 가챠가챠하는 것만으로 즐겁다」에서는 끝나지 않는 복잡함이 되어 버립니다. 서보의 설정 사정등은, 어떠한 조금 조작을 해도 좋은 느낌으로 움직이도록 생성해, 은폐하면 됩니다. 판단을 앞당긴 결과를 제품에 가두어 버리는 것입니다.

라고 하는 식으로 생성과 조작을 다른 클래스에 분리합시다...로 이야기는 끝나지 않습니다. 여기서, 조작하는 사람이 구체적으로 누군가에게 만들어 준다고 말해 버린다(구상 클래스형을 이용해 버린다), 조작은 생성자에 직접 의존해 버립니다. 정말로 생성의 세부 사항에 무관심하기 위해서는, 만드는 방법뿐만 아니라, 누가 만들어 주는지조차 관심을 지불해서는 안됩니다. 그래서 나오는 것이 "만드는 누군가"라는 추상 개념입니다. 의존하는 목적지는 거기입니다.

메모리 짱 (만들지 않는데 왜 사왔다)는 공주이므로 누구에게 부탁할지까지 생각하지 않습니다. 「뭐 누군가 만들어 주겠지요」라고 밖에 생각하지 않습니다. 그래서 괜찮습니다. 관심이 있는 것은 조작의 쪽이므로, 그쪽에 집중해 주는 것이 건전하고, 거기까지로 패키지를 완결시켜 버립니다. 그리고는 단체 테스트로 「누군가」로서 모크 팩토리를 사용하면, 패키지에 포함되는 코드는 모두 완성이군요. 하고 싶은 일만 하기 때문에 테스트 케이스도 간단합니다. 만들어주는 사람은 별도 패키지의 책무이므로 신경 쓰면 잃습니다.

요컨대, 객체를 생성하는 객체에 관해서, 이와 같이 상세한 모르는 의존을 일단 추상 그대로 두고, 객체를 이용하는 분에게만 주목하는 것, 즉, 종속성 역전 원칙 (Dependency Inversion Principle = DIP)의 팩토리 버전은 Abstract Factory 패턴입니다.

라는 느낌으로, 만화와 해설(코드는 노이즈가 되기 때문에 쓰지 않는다)로 개념만 아는 시리즈를 앞으로 22패턴, 솔로 어드벤트 캘린더로 해 나가려고 생각합니다.

우연히 첫회가 갑자기 가장 중요한 패턴으로 해설이 다소 많아졌습니다. 해설의 양은 패턴에 의해 불균일이 나온다고 생각합니다만, 아무쪼록 잘 부탁드립니다.

Twitter 하지만 조금 엔지니어 메모리 짱 를 잘 부탁드립니다.