기억하고싶은것들

브리지 패턴은 객체의 확장성을 향상하기 위한 패턴으로, 객체에서 동작을 처리하는 구현부와 확장을 위한 추상부를 분리한다.

상속을 통해서 객체의 계층을 분리하고 기능을 확장하지만 강력한 결합 관계와 불필요한 메서드도 상속에 같이 포함된다는 단점을 갖고 있다.

이러한 상속의 문제점은 브리지 패턴을 응용하여 해결할 수 있다.

브리지 패턴을 적용하려면 4개의 구성 요소가 필요하다.

• Implementor
  • Abstraction의 기능을 구현하기 위한 인터페이스 정의
• ConcreateImplementor
  • 실제 기능을 구현
• Abstract
  • 추상부 계층의 최상위 클래스
    구현부에 해당하는 클래스를 인스턴스를 가지고 해당 인스턴스를 통해 구현부분의 메서드를 호출
• refinedAbstract
  • 추상부 계층에서 새로운 부분을 확장한 클래스

상속은 강력한 결합을 가진다 -> 위임을 통해 느슨한 결합 관계로 변경 ( 복합 객체 구조 )

Inplementor

public interface HelloInterface {
    public String greeting();
}

ConcreateImplementor

public class Korean implements HelloInterface {

    @Override
    public String greeting() {
        return "안녕하세요";
    }

}

public class English implements HelloInterface {

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

}

패턴 설계 1

public class Language {
    public HelloInterface ko;
    public HelloInterface en;

    public void setEnglish(HelloInterface en) {
        this.en = en;
    }

    public void setKorean(HelloInterface ko) {
        this.ko = ko;
    }
}

복합 객체인 Language는 2개의 구현 클래스를 연결 ( 위임을 통해서 )

브리지 패턴은 복합 객체를 다시 재정의하여 추상 계층화된 구조이다.

위의 설계 1을 변형하여 구성 클래스의 연결 부분을 추상 계층으로 변경

추상화 변경을 실행하는 이유 : 각각의 계층이 독립적으로 확장/변경 가능하도록 하기 위해서

브리지 패턴은 기능을 처리하는 클래스와 구현을 담당하는 추상 클래스로 구별한다.

구현뿐 아니라 추상화도 독립적 변경이 필요할 때 브리지 패턴을 사용한다.

브리지는 구현 계층과 추상 계층 두 곳을 연결하는 다리라는 의미이다.

브리지 패턴을 적용하기 위해서는 계층을 잘 분리하는 것이 중요하다.

그리고 분리된 추상적 개념과 구현 계층을 연결해야 한다.

abstract

public abstract class LanguageAbstr {
    public HelloInterface lan;

    abstract public String greeting();
}

refinedAbstract

public class Message extends LanguageAbstr {

    public Message(HelloInterface lan) {
        this.lan = lan;
    }

    @Override
    public String greeting() {
        // bridge part
        return this.lan.greeting();
    }

}

추상 클래스는 상위 클래스와 하위 클래스 사이에서 역할을 분담한다

역할을 분담하는 추상 클래스의 계층은 새로운 기능을 생성하는 것이 아니라 기존의 기능을 분리하여 계층화한다.

브리지 패턴은 기존 시스템에 부수적인 새로운 기능들을 지속적으로 추가할 때 사용하면 유용한 패턴이다.

브리지 패턴은 새로운 인터페이스를 정의하여 기존 프로그램의 변경 없이 기능을 확장할 수 있다.

어댑터 패턴, 브리지 패턴

어댑터 패턴과 브리지 패턴이 유사해 보이기도 한다.

어댑터 패턴이 완성된 코드를 통합하고 결합할 때 사용되는 패턴이라면,

브리지 패턴은 처음 설계 단계에서 추상화 및 구현을 위해 확장을 고려한 패턴이라고 할 수 있다.

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

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

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

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

Factory Method Pattern

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

Abstract Factory Pattern

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

Abstract Factory VS Factory Method

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

팩토리 메서드 패턴은 

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

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

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

추상 팩토리 패턴은

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

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

Abstract Factory Pattern

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

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

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

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

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

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

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

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

( 위의 그림을 예시로 설명하면 새로운 그룹 -> 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 부품 관련 코드를 삽입해야 합니다. 

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

장점

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

단점

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

Singleton Pattern

싱글턴은 자원 공유를 위해 객체 생성 개수를 1개로 제한합니다.

싱글턴은 다른 생성 패턴과 달리 하나의 객체만 생성을 제한하는 패턴입니다.

그리고 생성된 객체는 공유되어 어디서든 접근할 수 있습니다.

싱글턴 패턴은 다음과 같은 상황에서 매우 유용합니다

• 공유 자원 접근
• 복수의 시스템이 하나의 자원에 접근할 때
• 유일한 객체가 필요할 때
• 값의 캐시가 필요할 때

예시 코드

public class Config {
	
	private static Config instance = null;
	
	private Config() {
		// private constructor
	}
	
	public static Config getInstance() {
		if (instance == null) {
			instance = new Config();
		}
		return instance;
	}
}

위의 예제에서는 multi thread 환경에서 어떠한 thread에서 getInstance를 호출하여 instance를 생성하는 시점에 

다른 thread가 해당 메서드를 호출하는 경우에 문제가 될 수 있습니다.

instance를 생성 중이긴 하지만, instance를 생성이 완료가 되지 않아서 null check 하는 로직에 true로 통과하여 싱글턴이 깨질 수 있습니다.

Multi Thread 환경에서의 Singleton

public class MultiThreadConfig {
	private MultiThreadConfig() {}
	
	private static class InnerClz {
		private static final MultiThreadConfig INSTANCE = new MultiThreadConfig();
	}
	
	public static MultiThreadConfig getInstance() {
		return InnerClz.INSTANCE;
	}
}

내부 정적 클래스를 선언하여 그 내부 클래스에서 인스턴스를 생성하도록 하는 방식

MultiThreadConfig 클래스에는 InnerClz 클래스의 변수가 없기 때문에, static 멤버 클래스더라도, 클래스 로더가 초기화 과정을 진행할 때 InnerClz 클래스는 초기화되지 않는다.
InnerClz 클래스는 getInstance()가 호출됐을 때 비로소 JVM 메모리에 로드되고, 인스턴스를 생성하게 됩니다.