SMALL

디자인 패턴의 목적 중에 생성에 해당하는 다양한 패턴들 중에 

팩토리 메서드 ( Factory Method )와 추상 팩토리 ( Abstract Factory ) 패턴은 언뜻 보면 비슷해 보인다.

그래서 정확히 각각의 패턴의 차이점이 무엇인지 알아보도록 하자.

 

먼저 각 패턴의 정의를 알아보자.

 

Factory Method Pattern

부모(상위) 클래스에 알려지지 않은 구체 클래스를 생성하는 패턴이며. 자식(하위) 클래스가 어떤 객체를 생성할지를 결정하도록 하는 패턴이기도 하다. 부모(상위) 클래스 코드에 구체 클래스 이름을 감추기 위한 방법으로도 사용한다.

 

Abstract Factory Pattern

인터페이스를 이용하여 서로 연관된, 또는 의존하는 객체를 구상 클래스를 지정하지 않고도 생성
다양한 구성 요소 별로 '객체의 집합'을 생성해야 할 때 유용하다. 
이 패턴을 사용하여 상황에 알맞은 객체를 생성할 수 있다.

 

Abstract Factory VS Factory Method

  팩토리 메서드 추상 팩토리
결합도를 낮추는 대상 클라이언트 코드와 인스턴스를 만들어야 할 구상 클래스를 분리시켜야 할때 사용 
어떤 구상 클래스를 필요로 하게 될지 미리 알 수 없는 경우 사용
( ConcreteProduct <->  Client )
클라이언트에서 서로 연관된 일연의 제품들을 만들어야 할때 사용
( ConcreteFactory <-> Client )
Factory 클래스에서 객체 생성 지원 범위 한 팩토리당 한 종류 
( create 메서드가 Factory 클래스에 1개)
한 팩토리에서 서로 연관된 여러 종류 모두 지원
( create() 메서드가 팩토리 클래스에 여러 개)
사용 목적  클라이언트 코드와 인스턴스를 만들어야 할 구상 클래스를 분리시켜야 할때 사용 
어떤 구상 클래스를 필요로 하게 될지 미리 알 수 없는 경우 사용 

클라이언트에서 서로 연관된 일연의 제품들을 만들어야 할때 사용 

 

위의 내용들을 이해한 내용을 나만의 용어로 정리해 보면

 

팩토리 메서드 패턴은 

사용자 코드와 concrete product와의 결합도를 낮추기 위해서 그 사이에 factory를 제공하는 것

실제 어떤 product를 사용자에게 넘겨줄지는 concrete factory가 결정한다. 

( 추가적으로 template 패턴이 조합되어 product를 생성하기 위한 일렬의 과정을 상위 factory를 통해 공통화할 수 있다. )

 

추상 팩토리 패턴은

팩토리 메서드의 확장판으로 객체의 집합을 생성 할 때 사용한다.

해당 팩토리를 통해 생성해야할 concrete product의 종류가 여러 가지 일 때 객체의 집합 별로 묶어서 생성할 수 있도록 도와준다.

 

LIST
SMALL

Abstract Factory Pattern

추상 팩토리 패턴은 큰 규모의 객체 군을 형성하는 생성 패턴이다.

팩토리 메서드 패턴을 확장한 패턴이라고 생각할 수 있다.

출처: https://johngrib.github.io/wiki/abstract-factory-pattern/#fnref:structure

추상 팩토리는 여러 개의 팩토리 메서드를 그룹으로 묶은 것과 유사하다.

추상 팩토리는 다양한 객체 생성 과정에서 그룹화가 필요할 때 매우 유용한 패턴이며 공장의 개념을 추상화한 것이다. ( 팩토리 메서드는 추상 팩토리와 동일하게 추상화 과정을 적용할 수 있지만 단일 그룹으로 제한한다.) 

 

각각의 그룹은 해결해야 하는 문제에 따라서 형성됩니다.

문제가 다양할 경우 새로운 객체를 생성해 그룹을 추가합니다. 

 

추상 팩토리는 생성 패턴을 그룹화된 구조로 분리합니다.

추상 클래스를 상속받는 하위 클래스를 추가해 새로운 그룹을 쉽게 만들 수 있지만 그룹의 하위 클래스를 추가하는 것은 쉽지 않습니다. 

( 위의 그림을 예시로 설명하면 새로운 그룹 -> ConcreteFactory1,2 && 그룹의 하위 클래스-> AbstractProductA, B )

 

AbstractFactory, ConcreteFactory

public abstract class Factory {
	
	abstract public TireProduct createTire();
	abstract public DoorProduct createDoor();
}

public class KoreaFactory extends Factory{

	@Override
	public TireProduct createTire() {
		return new KoreaTireProduct();
	}

	@Override
	public DoorProduct createDoor() {
		return new KoreaDoorProduct();
	}

}

public class StateFactory extends Factory{

	@Override
	public TireProduct createTire() {
		return new StateTireProduct();
	}

	@Override
	public DoorProduct createDoor() {
		return new StateDoorProduct();
	}

}

 

AbstractProduct, ConcreteProduct

public abstract class DoorProduct {
	abstract public String makeAssemble();
}

public class KoreaDoorProduct extends DoorProduct{

	@Override
	public String makeAssemble() {
		return "korea door product";
	}

}

public class StateDoorProduct extends DoorProduct{

	@Override
	public String makeAssemble() {
		return "state door product";
	}

}

 

public abstract class TireProduct {
	abstract public String makeAssemble();
}

public class KoreaTireProduct extends TireProduct{

	@Override
	public String makeAssemble() {
		return "korea tire product";
	}

}

public class StateTireProduct extends TireProduct{

	@Override
	public String makeAssemble() {
		return "state tire product";
	}

}

 

이제 각각의 클래스들은 정의가 되었고, 해당 클래스들을 호출하는 코드를 보자 

public class Main {
	public static void main(String[] args) {
		Factory factory = new KoreaFactory();
		TireProduct tire = factory.createTire();
		DoorProduct door = factory.createDoor();
		
		System.out.println(tire.makeAssemble());
		System.out.println(door.makeAssemble());
		
		factory = new StateFactory();
		tire = factory.createTire();
		door = factory.createDoor();
		
		System.out.println(tire.makeAssemble());
		System.out.println(door.makeAssemble());
		
	}
}

 

패턴의 장단점

앞에 살펴본 예제에서 각 그룹에 새로운 부품인 Engine을 추가해야 한다고 가정해봅시다.

새로운 부품을 추가할 때는 추상 클래스 그룹으로 분리된 모든 클래스에 Engine 부품 관련 코드를 삽입해야 합니다. 

추상 클래스의 경우 그룹을 나누는 것은 쉽지만 서브 생성 객체를 추가하는 것은 어렵습니다.

 

장점

  • 추상 팩토리의 그룹은 동일한 처리 로직을 갖고 있고, 다른 그룹으로 변경돼도 하위 클래스를 통해 선택적 객체를 다르게 생성할 수 있다
  • 추상 팩토리는 큰 변화 없이 시스템의 군을 생성하고 변경할 수 있다.

단점

  • 새로운 종류의 군을 추가하는 것이 쉽지 않다.
    ( 기존 군에서 새로운 군을 추가하여 확장할 때 모든 서브 클래스들이 동시에 변경돼야 한다)
  • 추상 팩토리는 팩토리 메서드와 비슷하지만 관리할 그룹이 많다 
    ( 계층의 크기가 커질수록 복잡한 문제가 발생 )

 

LIST
SMALL

Factory Method Pattern 정의

팩토리 메서드 패턴은 팩토리 패턴의 확장 패턴으로, 팩토리 패턴템플릿 메서드 패턴이 결합된 패턴이다

팩토리 패턴에 추상화를 결합하여 패턴을 확장한다

추상화를 통해서 골격(상위) 클래스를 제공하고, 상세한 구현은 하위 클래스로 위임

public abstract class Factory {
	public Product create() {
		return createProduct();
	}

	protected abstract Product createProduct();
}

public class ProductFactory extends Factory {

	@Override
	protected Product createProduct() {
		return new LGProduct();
	}
}

위의 예제에서 abstract class인 Factory가 골격(상위) 클래스이고, ProductFactory가 구현(하위) 클래스에 해당한다.

 

팩토리 메서드 패턴이 팩토리 + 탬플릿 메서드 패턴이라고 말하는 이유는 위의 abstract 클래스의 create 메서드를 보면 알 수 있다.

create 메서드는 abstract class의 abstract 메서드가 아니기 때문에 해당 메서드는 재정의가 불가능하다.

 

그렇기 때문에 해당 메서드에서 create를 호출할 때 실행하고 싶은 메서드를 나열하여 탬플릿화 할 수 있게 된다. 

public abstract class Factory {
	public void create() {
    
        // template method 
        createProduct();
        createSide();
        logDescription();
        
	}

	protected abstract Product createProduct();
}

 

실제 팩토리 메서드 패턴을 호출하는 코드를 보자

public class Main {
	public static void main(String[] args) {
		Factory factory = new ProductFactory();
		Product product = factory.create();
		product.name();
	}
}

이러한 형태라면, 사용자 코드에서는 create 메서드 내에 변화는 신경 쓸 필요가 없게 된다. ( 느슨한 결합 )

또한, 다른 종류의 Factory를 호출하는 코드로 바꾸어 끼고 싶다고 하여도, 다른 코드는 변경 없이 Factory를 생성하는 부분만 교체하면 된다.

 

LIST
SMALL
Factory Pattern 정의 

객체의 생성 동작을 별도 클래스로 분리하여 처리합니다.

또는 별도의 메서드를 호출하여 객체의 생성 동작을 처리합니다.

 

팩토리 패턴이 등장한 이유는 객체들 간의 의존관계를 분리하기 위해서 이다.

문제가 되는 Case를 보자 

public class Hello {
	public String greeting() {
//		return "안뇽!";
		Korean ko = new Korean();
		return ko.text();
	}
}

public class Korean {
	public String text() {
		return "안녕하세요";
	}
}

위의 Case에서는 Hello와 Korean 사이에 강한 결합 관계가 존재한다. 

 

이러한 관계를 끊어 주기 위해서, Factory Pattern을 사용한다. 

예시를 아래에서 보자.

public class Hello {
	public String greeting() {
//		return "안뇽!";
//		Korean ko = new Korean();
//		return ko.text();
		
		Language language = Factory.getInstance();
		return language.text();
	}
}

public interface Language {
	public String text();
}

public class Korean implements Language{
	
	@Override
	public String text() {
		return "안녕하세요";
	}

}

public class Factory {
	public static Language getInstance() {
		
		return new Korean();
	}
}

Hello 클래스에서 기존에 Korean 객체를 바로 생성하는 코드 대신에 Factory 클래스의 메서드를 호출하여 

강력한 결합력을 느슨한 관계로 변경하였다. 

 

또한, 추가적으로 Language Interface를 implement 하는 다양한 클래스를 두어 Factory를 통해서 다양한 객체를 반환해줄 수 있다. 

public class Hello {
	public String greeting() {
//		return "안뇽!";
//		Korean ko = new Korean();
//		return ko.text();
		
		Language language = Factory.getInstance("ko");
		return language.text();
	}
}

public class Factory {
	public static Language getInstance(String type) {
		
		if (type.equals("ko")) {
			return new Korean();	
		} else {
			return new English();
		}
		
	}
}
public interface Language {
	public String text();
}

public class Korean implements Language{
	
	@Override
	public String text() {
		return "안녕하세요";
	}

}

public class English implements Language{

	@Override
	public String text() {
		return "Hello !";
	}

}

 

Factory Pattern 장단점

팩토리 패턴을 통해 객체를 생성하면 유연한 코드 작성이 가능하고 동작도 쉽게 변경할 수 있다.

 

장점

  • 코드에서 생성과 관련된 모든 처리를 별도의 클래스 객체로 위임 가능
    ( 사용과 생성을 분리하는 과정에서 중복된 코드를 정리하는 효과 )
  • 유연성과 확장성 
    ( 개발 과정에서 클래스 이름이 변경돼도 코드를 일일이 수정하지 않고 팩토리 객체를 통해 변경 )

단점

  • 객체 생성을 위임하는 데 별도의 새로운 클래스가 필요
    ( 관리할 클래스 파일이 늘어난다 )

 

 

LIST

+ Recent posts