Design patterns - Creational Pattern

 

 

-Design patterns

: 객체지향 프로그램 작성할 때 문제를 해결해주는 패턴.

반복해서 재사용 가능한 문제해결 패턴을 모아놓은 것.

재사용 가능한 객체지향 프로그램의 설계 패턴.

 

-디자인 패턴 3가지 유형

1. Creational Pattern types

: 객체를 생성할 때 여러 클래스들간의 불필요한 의존성을 제거하는 구성, 어떻게 프로그램 구성을 할지

 

2. Structural Pattern types

: 클래스, 객체를 큰 구조를 만들기 위해 어떻게 구성해야 하는가,

기존 클래스의 구조를 바꾸지 않고 새로운 변경사항에 부흥할 수 있는 구조로 만들기 위해 어떻게.

 

3. Behavioral Pattern types

: 객체들이 맡는 역할들을 어떤 식으로 배치를 해야 나중에 추가적인 변경, 내부 데이터 구조가 바뀌더라도 큰 구조는 바뀌지 않도록 유지가 되게 하는가. 그런 문제들을 풀기 위한 디자인 패턴

 

Creational Patterns	Structural Patterns	Behavioral Patterns
Abstract Factory Factory method Builder Prototype  Singleton	Adapter Bridge Composite Decorator Façade Flyweight Proxy	Chain of Responsibility Command Interpreter Iterator Mediator Memento Observer State Strategy Template Method Visitor

 

1. Creational Pattern types

1) Factory Method Pattern

: 생성할 정확한 클래스 이름을 지정하지 않고, 의존도 없이 객체를 생성하는 것.

 

동기

: 객체를 만들기는 하고싶지만 어떤 클래스의 객체인지는 알고 싶지 않을 경우.

: 객체는 사용하고 싶지만 객체의 클래스에 의존성은 갖고 싶지 않은 경우.

의존성이 있다 = 객체의 내용이 바뀌면 나의 코드도 바뀌어야 한다.

 

장점 : coupling이 좋아진다. = weak해진다

 

상속관계

Product - ConcreteProduct

Creator - ConcreteCreator

 

의존관계

ConcreteProduct - ConcreteCreator

 

메서드 부연설명(오른쪽 박스)

AnOperation 구현시 오른쪽 내용대로 구현.

 

Creator 입장에서 객체를 만들 때 FactoryMethod를 부름.어떤 클래스의 객체를 만들지 클래스의 이름은 언급을 안함.자식 클래스가 대신에 객체를 만들어서 넘겨주기 때문.Creator와 ConcreteProduct 사이의 의존도는 weak해짐.

 

AnOperation메서드는 클라이언트가 사용하기 때문에 private이 아니라 public으로 선언되어 있어야 한다.

FactoryMethod는 외부 클라이언트가 직접 사용하지 않는다. AnOperation을 부르면 그 안에서 FactoryMethod를 부르게 되어있기 때문.

그리고 FactoryMethod는 자식 클래스가 오버라이딩해서 구현해야하는 메서드이다.

 

따라서 FactoryMethod는 클래스의 상속관계에 있는 클래스들만 호출하고 사용할 수 있는 메서드이다.

그렇기 때문에 protected메서드로 선언되어야 한다.

상속관계에 있지 않은 외부 클라이언트들은 access 할 수 없다.

 

예시)

앞으로 미래에도 폴더 프로그램은 사용이 될텐데 그 때 새로 나오는 문서 유형은 지금 모른다.

폴더 프로그램에서 새로운 문서를 만들 때 어떤 유형의 문서를 만들지는 몰라야한다.

하지만 새로 만들기는 할 수 있어야한다.

 

새로운 유형의 문서를 표현하는 객체를 만들어야 한다.

하지만 어떤 유형인지는 모르고도 만들 수 있어야 한다.

 

AnOperation -> NewDocument

FactoryMethod -> CreateDocument로 바뀐 것 뿐

FactoryMethod를 자식 클래스에서 오버라이딩 -> CreateDocument를 자식 클래스에서 implement 또는 오버라이딩.

 

예시)

자식클래스(PDF View)는  객체(PDF)만 만들어냄.

Application 클래스 입장에서는 객체(PDF, Picture, HWP) 와 연관이 없다.

 

 

2) Abstract Factory Pattern

: 여러 객체들을 만들어내는 factory들을 그룹화시켜서 클래스를 설계하는 방법

 

ProductA, B 객체를 2개 만들고 싶음.

A,B는 하나만 있지 않고 여러개로 구성됨.

ConcreteFactory1에서는 A1, B1 객체 2개를 조합해서 만들고 싶음.

ConcreteFactory2에서는 A2, B2

 

AbstractFactory에서는 CreateProductA, CreateProductB라고만 이야기를 하고 싶음.

클라이언트 입장에서는 특정 Product 조합에 의존성이 있지 않고 CreateProductA, CreateProductB 라고만 함. ConcreteFactory1, 2와 같은 어떤 객체의 클래스의 이름 언급안함

클라이언트 클래스는 AbstractProductA, B, AbstractFactory만 알고있다.

 

 

 

3) Singleton Pattern

: 객체생성에서 객체의 수가 오직 한개만 유지되는것으로 제한하도록 구성된 클래스 어떻게 만드냐.

 

동기

: 객체가 여러개이면 의미가 퇴색되는 상황 때문.

ex) 컴퓨터 실습실에 컴퓨터 여러대.

컴퓨터 클래스 만들어놓고 객체를 컴퓨터 대수만큼 여러개 만들어 내서 컴퓨터를 표현하는 것은 자연스러움.

그런데 프린터는 보통 1대에 여러 사람이 공유함.

그래서 프린터 클래스를 만들어놓고 원하는 수만큼 객체를 만들어 내는것은 부자연스러움.

 

프린터의 객체를 여러개 만들어내는 상황을 원천적으로 배제= 유일한 객체를 만듦 = singleton pattern

 

 

Singleton 클래스 안에 유일한 객체를 저장하는 변수 instance

하나만 있어야 하기 때문에 static으로 선언.

private Singleton에서 private로 선언하는 이유: 밖에 있는 클라이언트들이 Singleton클래스의 객체를 만드는 것을 금지.

객체를 만들려면 getInstance메서드를 통해 만들도록 구성.

instance == null 이면 아직 객체가 안만들어져 있다는 것. -> 객체 생성

 

 

기존의 Adaptee클래스의 인터페이스SpecificRequest() 코드를 바꾸지 않고 상속받음,

새로운 Target클래스의 인터페이스Request() 도 상속받음