Design Pattern - Factory Pattern

팩토리 패턴은 OOP(Object Oriented Programming)의 다형성과 추상화를 통한 정보 은닉이라는 개념이 동시에 적용된 객체 생성과 관련된 디자인 패턴이다.

DESCRIPTION

• 팩토리 패턴은 객체를 생성하는 좋은 방법에 관한 패턴이다.
• 팩토리 패턴은 조건에 따라 다른 객체를 생성하는 구체적이고 개별적인 코드를 은닉하고, 생성된 객체를 공통 인터페이스를 통해 반환한다.
• 사용자는 따라서 구체적이고 개별적인 객체 생성 논리에 대해 신경쓰지 않아도 되고, 또한 서로 다른 객체를 일관된 인터페이스를 통해 다룰 수 있게 된다.

DEEP and DEEP

정보 은닉

• 조건에 따라 각각의 인스턴스를 생성하는 조건 처리문을 은닉하고 사용자에게는 조건을 단지 입력하도록 추상화하여 서로 다른 객체를 보다 쉽게 생성할 수 있도록 돕는다.
• 뿐만아니라 인터페이스를 구현한 구현 클래스가 추가되더라도 곳곳에 흩어진 코드들에 하나의 조건문을 모두 추가해 줄 필요 없이, 오직 한 군데 팩토리 클래스의 코드만을 수정하고, 사용자는 필요한 조건 인자만을 다르게 넘겨주면 된다. 따라서 변경이 국지적으로 발생하여 변경에 쉽게 대처할 수 있고, 수정에 발생할 수 있는 실수를 줄여준다.

공통 인터페이스

• 사용자는 팩토리를 통해 반환 받은 공통의 인터페이스를 통해 서로 다른 객체를 일관된 방법으로 다룰 수 있다.
• 여러 자동차의 바퀴를 교체해 주는 정비소가 있다고 생각해보자. (for 문을 돌면서 자동차 바퀴를 교체해 준다고 상상해 보자. ) 만약 자동차 바퀴의 인터페이스가 자동차 별로 제 각각이라면 바퀴를 교체하기가 매우 어려울 것이다. 왜냐하면 각 자동차의 모델을 확인하고, 각 모델별로 바퀴를 교체하는 방법을 찾거나 기억의 저편을 더듬어야 한다. 자동차 엔지니어가 기억하고 처리해야할 정보의 양이 늘어나고, 경우의 수가 많아지니 자연스래 실수의 가능성도 그 만큼 높아진다. 따라서 자동차 바퀴 수리의 질이 낮아질 가능성이 높아진다.
• 반대로 모든 자동차 바퀴가 일정한 규격을 가지고 있다고 상상해 보자. 바퀴의 세부사항은 모두 다를 지라도 엔지니어가 다루는 인터페이스는 동일할 것임으로 엔지니어는 큰 고민 없이 일관된 방법으로 바퀴를 교체할 수 있다. 자연스레 바퀴를 수리하며 실수할 가능성은 낮아지고 수리의 질은 향상될 가능성은 높아진다. 엔지니어가 일하기가 수월하고 편해짐도 물론이다. 결과는 고객에게도 동일하게 유익하게 된다.

끄적끄적

• OOP의 다형성의 핵심은 다양한 것을 일관되게 처리할 수 있는 메커니즘(인터페이스, 추상 클래스)을 제공한다는 것이다.