2017

2017년 1월 13일 금요일

15. 의존성 주입(Dependency Injection)


정의
프로그래밍에서 구성요소간의 의존 관계가 소스코드 내부에서 만들어지는 것이 아닌 외부에서 생성되어 내부로 주입되도록 하는 패턴
 
 
목적
코드의 재사용성을 높이고 코드 변경 요청에 쉽게 대처할 수 있도록 기능에 따라 구조를 분리
 
Creater Injection
필요한 의존성을 모두 포함하는 클래스의 생성자를 만들고 그 생성자를 통해 의존성을 주입한다.
 
Setter Injection
의존성을 입력받는 세터(Setter) 메소드를 만들고 이를 통해 의존성을 주입한다.
 
Interface Injection
의존성을 주입하는 함수를 포함한 인터페이스를 작성하고 이 인터페이스를 구현하도록 함으로써 실행시에 이를 통하여 의존성을 주입한다.
 
장점
의존 관계 설정이 컴파일시가 아닌 실행시에 이루어져 모듈들간의 결합도 를 낮출 수 있다.
코드 재사용을 높여서 작성된 모듈을 여러 곳에서 소스코드의 수정 없이 사용할 수 있다.
모의 객체 등을 이용한 단위 테스트의 편의성을 높여준다.
 
단점
외부로부터 받아오는 객체들이 증가함에 따라 코드가 복잡해지고, 이해하기 힘들어진다.
 

14. MVC 패턴(MVC Pattern)


정의
컴포넌트를 데이터를 저장하는 모델, 실제 사용자에게 보이는 뷰, 모델과 뷰 사이에서 중재자 역할을 하는 컨트롤러로 나누어 독립적인 역할을 부여하는 패턴
 

목적
코드의 재사용성을 높이고 코드 변경 요청에 쉽게 대처할 수 있도록 기능에 따라 구조를 분리
 
Model
패턴 내에서 사용되는 모든 데이터가 저장된 공간
ModelViewControl에 대해서 그 어떤 정보도 알지 못함
Controller로부터 받은 데이터를 가공, 처리
Observer 패턴을 이용해 모델이 변경되면 등록된 View, Controller에 변경사항을 공지한다.
 
View
사용자가 직접 보여져야할 디자인 부분
Model이나 Controller의 동작 방식은 알지 못하고 오직 받은 데이터를 화면에 구성시키는 일만을 진행
 
Controller
ModelView사이에서 입력받거나 읽어 들인 데이터를 보낼 목적지를 정하는 중재자
ModelView의 변경을 모니터링하고 상호 통보한다.
View의 사용자의 입력을 Command패턴을 이용해 위임받아 Model로 보낸다.
 
장점
컴포넌트가 기능별로 분리되어 코드의 재사용, 확장이 용이해져 유지보수가 편해진다.
하나의 모델로 여러 개의 뷰를 구성할 수 있다.
 
단점
뷰는 모델을 이용하기 때문에 서로간의 의존성을 완전히 지울 수 없다.

13. 컴포지트 패턴(Composite Pattern)


정의
객체들을 트리 구조로 구성하여 부분과 전체를 나타내는 계층구조로 만드는 패턴
 

 
목적
사용자로 하여금 개별 객체와 다른 객체들로 구성된 복합 객체의 차이를 알 필요 없이 같은 똑같은 객체로 취급하게 만듬
 
장점
개별 객체와 복합 객체를 똑같이 취급하므로 코드의 길이가 짧아진다.
새로운 종류의 구성요소를 쉽게 추가할 수 있다.
 
단점
새로운 구성요소의 추가는 쉬우나 복합체에 제약조건을 가하기 힘들다.
 

12. 이터레이터 패턴(Iterator Pattern)


정의
컬렉션 객체의 구성 방식과 관계없이 객체 내의 모든 요소들을 순차적으로 접근할 수 있는 기능을 제공하는 패턴
 

 
목적
컬렉션 객체의 내부 구조를 드러내지 않고 보관된 개체들에 대한 순차적 접근 방법 정의
 
장점
컬렉션의 종류에 구애받지 않고 사용할 수 있다.
집합 객체에 다양한 순회 방법을 정의할 수 있다.

11. 상태 패턴(State Pattern)


정의
클래스 내부의 상태의 변화에 따라 동일한 요청에 대하여 클래스가 취하는 행동 또한 변하는 패턴
 

 
목적
객체의 상태를 각각의 클래스로 캡슐화 하여 동적으로 행동을 교체할 수 있도록 한다.
 
장점
상용자는 자신의 행동에 의해 객체 내부에서 어떤 행동을 실행하는지 알 필요가 없다.
 
단점
상태마다 클래스를 생성해야해 상태가 많아지면 클래스의 수가 증가한다.
 
Strategy 패턴과의 차이점
State 패턴 객체 내부의 상태에 따라 현 상황에 맞는 행동이 실행
Strategy 패턴 사용자가 어떤 전략을 사용할지 직접 선택하여 행동을 실행
 

10. 템플릿 메소드 패턴(Template Method Pattern)


정의
상위 클래스에서는 알고리즘의 골격만을 미리 정의해 두고 각 단계에서 수행될 구체적인 행동은 서브클래스에서 구현하도록 한 패턴
 
 

목적
알고리즘의 구조는 그대로 유지하면서 서브클래스에서 특정 단계의 행동을 재정의하여 사용한다.
 
장점
사용자가 직접 다루어야 할 객체의 수가 줄어든다.
사용자와 서브시스템간의 약한 결합도를 유지해 서브시스템의 추가가 쉽다.

09. 퍼사드 패턴(Facade Pattern)


정의
사용자에게 복잡한 과정은 드러내지 않고 일련의 하위 과정들을 아우르는 상위 수준의 인터페이스를 제공하여 하위 서비스들을 사용하기 쉽게 만든 패턴
 

 
목적
서브시스템 내의 인터페이스 집합에 대한 획일화된 하나의 상위 수준의 인터페이스를 제공
 
장점
사용자가 다루어야 할 객체의 수가 줄어든다.
사용자와 서브시스템간의 약한 결합도를 유지해 서브시스템의 다양화를 쉽게 합니다.

Adapter, Decorator와 차이점
Adpater 호환성을 위해 기존의 인터페이스를 사용하고자 하는 다른 인터페이스로 변환
Facade 복잡한 내부를 숨기고 간편하게 사용할 수 있도록 만들기 위해 인터페이스를 통합/단순화
Decorator 인터페이스를 변경하지 않고 객체를 새로운 객체로 감싸 행동을 동적으로 추가
 

08. 어댑터 패턴(Adapter Pattern)


정의
기존 인터페이스가 사용하고자 하는 인터페이스와 호환되지 않을 때 기존 인터페이스를 어댑터로 감싸 사용하고자 하는 다른 인터페이스로 변환하여 사용 가능하도록 만드는 패턴
 

 
 
목적
서로 다른 구조를 가지는 인터페이스를 연결하여 호환 가능하도록 함
 
클래스 Adapter
장점
Adapter 전체를 다시 구현할 필요가 없으며 행동을 오버라이드할 수 있다.
 
단점
상속을 사용하기 때문에 특정 Adaptee에만 적용되어 유연성이 떨어진다.
객체 Adapter
장점
구성을 사용하기 때문에 Adaptee클래스 뿐만 아니라 서브 클래스에 대해서도 Adapter 역할이 가능하다
 
단점
AdapteeAdapter 클래스의 대부분의 코드를 구현해야 하여 코드의 양이 늘어나게 된다.
 

07. 커맨드 패턴(Command Pattern)


정의
사용자가 요구하는 명령어를 객체에 캡슐화 하여 저장하고, 저장된 명령에 대해서 redo, undo의 기능을 제공하는 패턴
 

 
목적
명령을 요구하는 객체와 그 요청을 수행하는 객체의 분리
 
장점
요청 내역을 큐에 저장, 로그로 기록, 작업 취소 기능도 지원
 
단점
객체 구성 부분이 추가되면 추상부분부터 수정하여 추가해야한다.

06. 싱글톤 패턴(Singleton Pattern)


정의
객체가 전체 프로그램 내에서 단 하나만 존재하여야 할 때 인스턴스가 하나 뿐인 객체를 제공하는 패턴
 
 
목적
어디서든 접근 가능한 유일한 인스턴스를 제공
 
장점
객체가 사용되기 전까지 생성을 지연시켜 static에 비하여 자원 낭비가 적다.
 
단점
Singleton 패턴이 글로벌 인스턴스로써 사용될 때 인터페이스가 아닌 코드에 의존하게 된다.
singleton 패턴은 인스턴스가 스스로 생성과 소멸을 제어하기 때문에 single responsibility principle(단일 책임 원칙)에 위배된다.
 
- single responsibility principle(단일 책임 원칙) - 하나의 클래스마다 하나의 행동만을 두어 다른 클래스와의 의존도를 낮추고 코드 수정이 용이하게 한다.(클래스를 변경하는 이유는 단 한가지여야 한다.

05. 추상 팩토리 패턴(Abstract Factory Pattern)


정의
객체 내에서 구체적인 메소드를 정의하지 않고 메소드의 구성은 서브 클래스로 미루어 서로 연관된 객체 군을 생성하는 패턴
 

 
목적
서로 연관성을 가지는 다양한 객체들의 생성을 하나의 팩토리에서 관리
 
장점
구체적인 구현 클래스를 사용자로부터 분리시킨다.
 
단점
새로운 종류의 제품을 추가하기 위해서는 abstract factory와 이에 의존하고 있는 모든 서브 클래스들을 수정해야 한다.
 
Factory Method와의 차이점
Factory Method 상속을 이용해 객체를 생성, 클래스의 확장과 메소드의 오버라이드를 이용, 사용자가 요구하는 실제 제품을 만든다.
Abstract Factory 객체 구성을 이용, 제품군을 만들기 위한 추상, 제품을 생산하기 위한 공장(객체)을 만든다.

04. 팩토리 메소드 패턴(Factory Method Pattern)


정의
객체를 생성하기 위한 Interface만을 미리 정의해 두고 실제 인스턴트를 생성하는 일을 서브클래스에 위임하는 패턴
 
 
 
목적
하위 클래스에 객체 생성의 책임을 넘겨주어 객체의 생성과 객체의 사용을 분리시킨다.
 
장점
객체의 생성을 한 클래스에서 관리할 수 있다.
제품을 생성하는 부분과 사용하는 부분이 분리된다.
 
단점
생성할 객체의 종류가 달라질 때 마다 새로운 하위 클래스를 정의해야 한다.
 

03. 데코레이터 패턴(Decorator Pattern)


정의
기존 객체를 변형하는 것이 아니라 기능 추가가 필요할 때 새로운 Decorator 객체로 기존 객체를 감싸 행동을 동적으로 추가할 수 있도록 만든 패턴
 

 
목적
실제 상속으로 서브클래스를 계속 만드는 방법이 효율적이지 못할 때 다른 객체에 영향을 주지 않고 행동을 추가하기 위하여 사용
객체의 기본적인 기능과 그 기능을 꾸며주는 객체를 완전히 분리시키는 패턴
 
장점
런타임 도중에 Decorator를 객체와 연결하는 방식을 통하여 새로운 행동을 추가할 수 있다.
Decorator 패턴은 특정 행동이 필요할 때 그 행동을 추가함으로써 현시점에 불필요한 요소의 개발을 최소화 할 수 있다.
 
단점
Decorator를 사용하다보면 작은 규모의 잡다한 객체들이 많아질 수 있다.
Decorator내부에 특정 객체가 포함되어 있는지 식별해내기 힘들다.

02. 옵저버 패턴(Observer Pattern)


정의
주제 객체의 상태가 바뀔 때 마다 그 객체에 의존하는 모든 Observer객체가 변경 내용을 통지받고 지니고 있던 값을 자동으로 갱신하는 패턴.
 

 
목적
주제 객체의 상태가 변하면 이 객체에 의존하는 모든 Observer 객체들이 해당 상태변화를 통지받아 인지할 수 있도록 객체들 간의 one-to-many 의존관계를 정의
 
Push 방식 주제 객체의 상태가 변경될 때 마다 의존하고 있는 모든 Observer 객체들에게 공지
Pull 방식 주제 객체에 의존하는 Observer가 갱신된 상태에 대한 정보가 필요할 때 getter를 이용하여 주제 객체로부터 갱신된 데이터를 수령
 
장점
주제 객체와 Observer 객체간의 loose coupling을 통해 객체의 변경에 유연하게 대처할 수 있다.
주제 객체에 Observer의 등록/탈퇴가 자유롭다.
 
단점
상태가 변경되었다는 사실만을 주고받기 때문에 여러 주제객체에 의존하는 Observer의 경우 동일한 값의 변경에 대하여 반복적인 갱신이 이루어질 수 있다.

01. 전략 패턴(Strategy Pattern)


정의
동일한 목적을 가지는 알고리즘들을 하나의 인터페이스로 묶고, 각각의 알고리즘을 캡슐화 하여 교환하여 사용할 수 있도록 한 패턴


 
목적
목적은 하나로 동일하나 그 목적을 달성할 수 있는 알고리즘은 다양할 때 사용
 
장점
행동들을 서로 다른 클래스로 캡슐화하기에 조건문을 사용할 필요가 없다.
서브클래싱을 사용하지 않아 구현한 알고리즘과 행동들을 재사용 할 수 있다.
 
단점
적합한 행동을 선택하기 위해서는 사용자가 사용되는 다양한 전략에 대하여 미리 인지하고 있어야 한다.
행동별로 클래스를 생성하여 프로그램 내의 객체의 수가 증가한다.
Template Method와의 차이점
Strategy 패턴 알고리즘 전체를 캡슐화, 구성과 위임을 통하여 알고리즘을 캡슐화, 구상과 위임을 사용하여 알고리즘 전체 수정 가능
Template Method 패턴 알고리즘의 각 단계를 캡슐화, 상속을 이용하여 알고리즘을 캡슐화, 상속으로 인한 코드 재사용이 가능, 상속을 사용하여 변경 가능한 부분과 그렇지 않은 부분이 존재