[KO]Design Pattern: Factory Method
--
디자인 패턴이란 Object-Oriented 프로그래밍을 하면서 발생하는 일반적인 문제를 해결하기 위한 방법을 정의해 놓은 것입니다.
디자인 패턴이란 어떠한 모듈이나 라이브러리가 아닌, 일종의 개념이라는 것으로 흔히 사용하는 프레임워크는 보통 디자인 패턴을 적용할 수 있는 방법으로 작성되어 있습니다.
그럼에도 불구하고 디자인 패턴을 알아야 하는 중요한 이유가 존재합니다.
왜 우리는 디자인 패턴을 알아야 하는가?
- 디자인 패턴을 알게 됨으로 인해, 우리는 객체 지향 프로그래밍에서 발생하는 일반적인 문제가 무엇인지 알 수 있습니다.
- 다른 개발자에게 작성한 코드를 설명할 때, 공통으로 이해할 수 있는 언어를 사용할 수 있게 됩니다. 하나의 프로토콜이라 할 수 있습니다.
- 효율적인 코드에 대해 한번 더 생각하게 됩니다.
위와 같은 이유로 인해 우리는 디자인 패턴을 알아야합니다.
앞으로 몇회가 될 지는 아직 알 수 없지만, 각종 디자인 패턴에 대해 공부해보고자합니다.
물론 제가 PHPer 이므로 예제는 PHP로 작성 될 것입니다.
Factory Method
팩토리 메소드 패턴은 디자인 패턴 중 Creational 패턴입니다. 팩토리 메소드 패턴은 SOLID 원칙 중 D에 해당하는 의존관계의 역전 원칙(DIP: Dependency Inversion Principle)을 달성할 수 있도록 합니다.
Factory Method 패턴은 어떠한 일을 하는가?
- 클라이언트(실제 오브젝트를 사용하려는 메소드를 의미)가 오브젝트의 생성 로직을 알지 못해도 오브젝트를 생성하는데 문제가 없도록 합니다.
- 공통 인터페이스를 사용하여 필요한 최소한의 정보를 통해 상황에 맞는 오브젝트를 생성할 수 있습니다.
팩토리는 말 그대로 객체를 생성하기 위한 공장입니다. 이 공장에서는 생성할 객체의 세부사항은 전혀 알지 못합니다. 단순히 생성만 할 뿐입니다.
Factory Method 패턴을 사용하면 어떠한 이점이 있는가?
- 클래스 간의 강한 결합을 방지
- 복잡한 생성 로직을 가진 오브젝트의 생성을 클라이언트가 간단하게 할 수 있다.
- 새로운 타입의 오브젝트가 추가되었을 때, 클라이언트의 코드를 변경할 필요가 없다.
- 코드를 보다 더 유연하게, 유지보수가 가능하게, 확장가능하게 작성할 수 있다.
예제를 통해 알아보는 Factory Method 패턴
저는 사실 글로 설명된 것을 읽으며 이해하는 것을 매우 좋아합니다. 코드만 해석하는 건 어려운 일이기도하지요. 하지만 적절한 예제는 이론을 이해하는 데 매우 중요한 역할을 하는 것도 사실입니다.
우리는 게임을 만드는 간단한 프로그램을 가지고 있습니다. 하단의 간단한 코드가 현재 우리가 가지고 있는 프로그램이지요.
Factory Method 패턴을 적용하지 않은 간단한 프로그램
매우 간단하고 알기 쉬운 프로그램이지만, 이 프로그램에는 문제가 있습니다. 클래스를 수정한다면 클라이언트의 코드를 전부 수정해야한다는 것에 있습니다.
위의 프로그램이 살짝 더 복잡해진다고 생각해보도록 합시다.
Factory Method 패턴을 적용하지 않은 조금 복잡해진 프로그램
API를 통해 게임을 제조하는 날짜에 따라 판매 가격을 다르게 설정해야 한다고 가정해봅니다. 이 경우, AbstractGame을 상속받은 모든 클래스는 생성 될 시 판매 가격과 날짜를 입력받아야만합니다. 하단의 코드와 같은 수정이 생길 것으로 예상됩니다.
클래스에서는 가격과 날짜라는 단 두개의 프로퍼티가 추가되었습니다. 사실 이 상태만을 보면 많은 부분이 변경되지 않았기 때문에 문제가 없는 것이라 생각할 수 있습니다.
하지만 분명 문제는 존재합니다. Zelda와 Pokemon이라는 클래스는 프로그램에서 단 한 곳에서만 생성된 것은 아닐 것입니다. 생성된 모든 코드를 수정해 주어야 하는 문제가 생기는 것입니다.
Factory Method 패턴을 적용해보기
위에서 팩토리는 단순히 오브젝트를 생성하는 공장이라는 의미라고 말씀드렸습니다.
클래스의 변경에 의해 코드를 변경하는 것을 최소화 하기 위해(이를 클래스 간의 결합도를 낮추는 것이라 표현할 수 있습니다), 생성만을 담당하는 Factory를 만들어보도록 하겠습니다.
게임을 생성하기 위한 팩토리를 생성하였습니다.
이제 우리는 클라이언트 코드를 다음과 같이 변경할 수 있습니다.
만약 우리가 처음부터 팩토리를 가지고 있고, getGameTitle() 메소드를 실행하기 위해 위와 같은 코드를 작성하였다면, 오늘의 판매가($price) 및 날짜($today) 프로퍼티가 추가되었을 때, 클라이언트 코드에는 영향이 없었을 것입니다.
코드를 변경한 이후 팩토리 메서드가 정확하게 동작하는 것을 확인한다면, 클라이언트 코드에서는 동작에 문제가 없음을 어느정도 보장할 수 있게 되는 것입니다.
맺음말
코드를 작성할 때는 간단하게 작성을 하지만, 시간이 지난 이후 사양을 변경할 필요가 생겼을 때, 디자인 패턴이 적용되어있지 않았을 경우 사이드 이펙트가 두려워 코드를 손대지 못하는 경우가 생깁니다.
이러한 위험성을 최대한 줄이고자 디자인 패턴을 공부할 필요성이 있습니다. 저 또한 더 나은 코드 작성 및 리팩토링을 위해 현재 디자인 패턴을 공부하는 중입니다.
틀린 내용 / 추가하면 좋을 내용 / 참고하면 좋을 자료 등에 대한 피드백은 언제나 환영합니다.
다음에는 Factory Method Pattern을 조금 더 발전시킨 Abstract Factory Pattern에 대해 기사를 작성하도록 하겠습니다.
