[KO]Design Pattern: Abstract Factory

Jangwook Kim
Dec 25, 2019 · Unlisted

우리는 지난 포스트를 통해 Factory Method Pattern에 대해 알아보았습니다.

Factory란 오브젝트의 생성만을 담당하는 클래스로, 객체의 생성을 단순화 하여 관리를 편하게 하는 것에 의미가 있습니다.


Factory Method 복습

GameFactory라는 팩토리를 이용하여 Game 인터페이스를 구현한 ZeldaPokemon 클래스의 오브젝트를 생성하고 있습니다.

객체의 생성에 대한 로직을 팩토리에 전부 작성하였기 때문에, 코드의 수정이 필요할 때 Factory만을 확인할 수 있게 합니다.

팩토리 메소드에 대한 평가

현재는 Game 인터페이스의 구현이 두개밖에 존재하지 않습니다. 만약 게임의 종류가 늘어 100 종류의 게임이 생성된다면 어떻게 될까요?

Factory 클래스 내부의 분기문이 엄청나게 길어지게 될 것입니다. 이는 수정이 필요한 부분을 찾아내는데 시간이 걸리며, 길어진 코드로 인해 생산성도 떨어지는 결과를 초래하게 될 것입니다.

그래서 우리는 팩토리 메소드를 조금 더 간단히 변경할 필요성이 있음을 알게 됩니다.


Abstract Factory

Factory Method Pattern의 문제가 분기문이 늘어나는 것이라면, 분기문을 없애는 방식으로 GameFactory 클래스를 변경할 수 있습니다.

여기서 하나의 의문이 생깁니다. 단순하게 분기문을 상속된 클래스로 변경하는 단순한 것이 Abstract Factory Pattern인가 하는 것인데요.

Factory Method Pattern과 다른 점을 꼽는다면 Abstract Factory는 연관된 생성 메소드를 하나로 묶는 것에 있습니다.

게임 패키지를 만든다는 가정 하에, 우리는 설명서, 일러스트, 씨디를 만들고, 그것을 상품화 하는 과정이 필요합니다.

Factory Method 패턴에서는 단 하나의 생성 메소드만 존재했지만, Abstract Method에서는 생성 메소드와 더불어 필요한 다른 메소드도 하나의 클래스로 관리할 수 있게 하였습니다.

Abstract Factory 확장

각 게임 패키지를 생성하는데 관련한 모든 메소드를 하나의 클래스에서 관리하는 방법으로 코드를 이해하는 것이 한층 더 쉬워진 것을 알 수 있습니다.

최상위 추상 클래스를 통해 콘크리트 클래스가 어떠한 행동을 할 것인지 유추할 수 있으며, 콘크리트 클래스의 메소드는 콘크리트 클래스 자체에 구현하므로 요청사항의 변경에 대응하는 것도 매우 간단하게 되었습니다.


맺음말

무작정 사용해왔었던 디자인 패턴들이 왜 만들어졌는지, 이해를 해 나가는 과정은 생각했던 것보다 더 재미있네요.

다음 포스트에서는 Adapter Pattern에 대해 알아보도록 하겠습니다.


Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store