[개발자 책읽기] Java로 해석한 GoF 의 Design Pattern (생성 - 팩토리 메서드 패턴)

해당 글은 Gang of Four의 디자인 패턴 이라는 책을 읽고 학습한 내용을 정리 및 회고하는 글 입니다. 자세한 사항은 YES 24 GoF의 디자인 패턴 에서 확인해주세요.

 

GoF 의 디자인 패턴 - 재사용성을 지닌 객체지향 소프트웨어의 핵심 요소

 

• 프로텍 미디어
• 지은이: 에릭 감마, 존 블리사이드스, 리처드 헬름, 랄프 존슨
• 옮긴이: 김정아

 

 

• 다음 글을 함께 읽으면 좋습니다.
  • 클래스 다이어그램 이해하기

---

 

팩토리 메서드 패턴, Factory Method Pattern

 

객체를 새성하기 위해 인터페이스를 정의하지만, 어떤 클래스의 인스턴스를 생성할지에 대한 결정은 서브 클래스가 내리도록 합니다.

• Factory Method 는 다른 이름으로 Virtual Constructor 라고도 한다.

 

동기

 

사용자에게 다양한 종류의 문서를 표현할 수 있는 응용 프로그램 프레임워크가 있다고 했을 때, 처음에는 PdfDocument 만 존재해 모든 코드가 PDFDocument 에 의존적이게 개발되었다고 하자.

 

하지만 시간이 지나고 ExcelDocument 와 HwpDocument 가 필요하다는 요구사항이 발생하면 기존에 Document 를 생성하기 위해 구성된 코드를 다방면으로 수정해야 한다.

 

즉, 현재의 코드는 PdfDocument 에 의존적이게 되었다.

 

이러한 상황이 발생하게 된 이유는 생성의 책임을 분리하지 않았기 때문에 발생한다.

 

이 때 생성의 책임만을 갖도록 하는 Factory 클래스를 이용할 수 있고 이를 팩토리 메서드 패턴으로 해결할 수 있다.

 

패턴에 대해

 

Factory Method 패턴은 객체를 생성하는 Client 에서 new 를 통해 객체를 생성하는 것이 아니라 Factory 를 통해 new 연산자를 대신 해주는 객체를 만드는 것이다.

 

구현

 

 

참여 객체

• Creator
  • RoleFactory
• Product
  • Role
• ConcreteProduct
  • AdminRole
  • MemberRole

 

Factory Class

 

public class RoleFactory {

    public Role createRole(RoleType type) {
        if (RoleType.ADMIN.equals(type)) {
            return new AdminRole();
        } else if (RoleType.MEMBER.equals(type)) {
            return new MemberRole();
        }

        throw new NullPointerException();
    }
}

 

우선 Product 를 생성하는 Factory 클래스이다.

 

해당 클래스에서는 Role 을 생성하는 한 가지의 책임만 존재한다

 

이렇게 된다면 이 클래스를 변경하는 이유는 Product 가 추가될 떄 라는 한 가지 이유만 존재한다.

 

하지만 변경이 된다라는것 자체는 한 번 생각해볼 여지가 존재한다.

 

즉, SRP 를 만족하나 OCP 를 만족하지 않는 구조가 된다.

 

Product Class

 

public interface Role {
    String describeRole();
}

public class MemberRole implements Role {

    private String information = "This is Member Role";

    @Override
    public String describeRole() {
        return information;
    }
}

public class AdminRole implements Role {

    private String information = "This is Admin Role";

    @Override
    public String describeRole() {
        return information;
    }
}

public enum RoleType {
    ADMIN, MEMBER
}

 

위의 코드들은 Factory 에서 생성하게될 Product 클래스이다.

 

ConcreteProduct 는 모두 Product 인 Role 인터페이스를 상속받는 형태로 구성된다.

 

마지막에 존재하는 RoleType 은 Factory 에서 생성할 Role 들을 구분할 수 있도록 구분자의 역할을 할 수 있는 Enum 이다

 

Client

 

public class Client {
    public static void main(String[] args) {
        RoleFactory factory = new RoleFactory();

        Role role = factory.createRole(RoleType.ADMIN);

        System.out.println(role.describeRole());
    }
}

 

클라이언트 코드에서는 factory 에게 RoleType 을 넘기게 되고 RoleType 에 따라 적절한 Role 를 반환받게 된다.

 

장점과 단점

 

장점

• 생성과 구현을 분리할 수 있다.
• SRP 를 잘 지킬 수 있다.

 

단점

• 많은 Product 의 Subclass 들로 인해서 복잡해질 수 있다.

 

정리

 

여러 소프트웨어에서 Factory Method 를 시작으로 점점 Abstract Factory 나 Prototype 으로 발전하게 된다.

 

즉, 더 복잡한 생성 패턴의 기본이라고 할 수 있는 패턴이며 가장 이해하기 쉬운 패턴이다.

 

GoF 에서 소개되는 많은 디자인 패턴들이 모두 사용되고 있는것 같지는 않다.

 

여러 패턴들 중에서 몇몇 유용하고 쓸모있는 패턴들만 주로 사용이 되는데, 이 Factory Method 역시 자주 사용되고 있는 패턴이라는 생각이 든다.