빌더 패턴

제품을 구성하는 구성 요소들을 먼저 결정 하고 이를 조합하는 식으로 객체를 만들수 있다.
객체를 만드는 요소들이 독립적일 때 빌더객체에 살을 붙여나가는식으로 손쉽게 추가하고 확장할 수 있다.
실제제품은 최종적인 빌더 객체로부터 산출할 수 있다.
팩토리 패턴과 유사하나 차이점은, 빌더 패턴은 복잡한 객체의 단계별 생성에 중점을 두고, 팩토리패턴은 제품의 유사군들이 존재하는 경우 유연한 설계에 중점을 둔다.
빌더패턴은 생성의 마지막 단계에서 객체를 생성하지만( build()), 팩토리 패턴은 만드는 즉시  객체를 생성한다.(newInstance())
 

이터레이터 패턴

내부 표현 방법을 노출하지 않고 복합객체의 원소에 차례대로 접근하는 방법을 제공한다. 복합 객체 요소들의 내부 표현방식을 모르더라도 외부에서 각 원소에 차례대로 접근할 수 있도록 한다.
 

프로토타입 패턴

프로토타입의 인스턴스를 이용해서 생성할 객체의 종류를 등록하고 이렇게 만들어진 견본을 복사해서 새로운 객체를 생성한다.
프레임워크와 생성할 인스턴스를 분리하고 싶을 때 사용한다.
인스턴스화해야 하는 각 객체 종류마다 여러가지 다른 수많은 서브클래스를 만들어야 하는 단점이 생긴다.
 

스트래티지 패턴

여러 알고리즘을 캡슐화하여 상호교환할 수 있도록 한다. 스트래티지 패턴은 알고리즘의 사용을 다양한 방법으로 변경할 수 있게 한다. (상속과 다형성)
 

템플릿 메서드 패턴

알고리즘의 동작에 있어서 뼈대를 정의한다. 템플릿 메서드는 알고리즘의 구조 변경없이 하위 클래스의 그 동작을 다시 정의할 수 있다. 즉, 알고리즘의 구조는 그대로 유지하면서 특정단계의 서브 클래스만 새로 정의하도록 할 수 있다.
알고리즘의 공통적인 부분을 우선 구현하고 나머지 세부 동작은 하위 클래스에서 다양하게 구현하고자 할 때,
그리고 공통된 클래스로부터 하위 클래스 간에 공통되는 동작을 추출하여 코드의 중복을 방지하고 하위 클래스의 확장을 제어하고자 할 때 사용한다.
 

팩토리 메소드 패턴

객체를 생성하는 인터페이스를 정의한다. 어떤객체를 만들지는 하위클래스가 담당한다. 즉, 객체만드는것을 직접하지 않고 하위클래스에게 맡긴다.
 

어댑터 패턴

클래스의 인터페이스를 클라이언트들이 원하는 다른 인터페이스로 바꾸는 것이다. 어댑터 패턴은 인터페이스 호환성 문제 때문에 같이 쓸 수 없는 클래스들을 연결하여 잘 동작하게 해준다.
 

미디에이터 패턴

객체들이 상호작용하는 방법을 하나의 객체에 정의한다. 미디에이터(중재자) 패턴은 명시적으로 서로 참조해서 객체를 유지함으로써 느슨한 결합을 유지하고 각 객체의 상호작용을 독립적으로 할 수 있다. 즉, 클래스들이 직접적으로 복잡한 관계를 맺고 있어 서로 간의 의존관계가 불명확하고 이해하기 어려울 때 중재 클래스를 도입해서, 클래스 간의 직접적인 관계를 끊고 복잡한 상호연결 관계를 중재 클래스 하나로 전환해줄 수 있는 형태의 클래스 구조이다.
 

데코레이터 패턴

동적으로 생성된 객체에 기능을 추가할 수 있다. 객체에 추가적인 요건을 동적으로 첨가하여 서브클래스를 만들고 이를 통하여 기능을 유연하게 확장하는 방법을 제공한다. 데코레이터 패턴은 기능을 확장하기 위한 상속에 대해 유연한 대안을 제공한다. 래퍼(Wrapper) 패턴으로도 알려졌다.
 

PAC 패턴

PAC는 Presentation, Abstraction, Control 세단어의 조합이다.
프레젠테이션은 시각적인 동작을 위한 컴포넌트를 핸들링하고,
추상은 데이터를 핸들링,
컨트롤은 이 둘을 연결한다.
 
시스템의 복잡성이 증가하므로 자칫 잘못적용하면 독이 될수 있다.
이 아키텍처는 수평적 분해와 수직적 분해를 모두 해결해야한다.
 

MVC 패턴

Model, View , Controller 패턴
Model은 객체나 데이터의 가공을 책임진다.
뷰는 필요에 따라 모델로부터 객체의 상태를 요청하여 표현할 수 있다.
컨트롤러에게 전달 시 상태정보를 같이 보낼 수 있다. 중요한 것은 모델로부터 받은 객체의 상태에 의해 뷰가 직접 제어, 가공하는 일은 없어야 한다. 모든 가공은 제어는 컨트롤러에게 위임한다.
컨트롤러는 객체의 흐름을 책임진다. 뷰로부터 받은 메시지를 파악하여 해당 객체를 어떻게 가공하여 모델로 전달할지 결정한다.
모델과 뷰의 의존성을 어떻게 제어 하느냐에 따라 MVC, MVP, MVVM등으로 나뉘게 된다.
 

옵저버(Publisher – Subscriber) 패턴

컴포넌트들의 상태를 동기화 하는데 유용하다.
상태변화가 발생할때 객체에 종속된 컴포넌트들에게 이벤트를 전달한다.
이벤트가 변하는 객체의 상태를 직접적으로 체크 할수 없으며, 통지만 받을수 있다.
옵저버 패턴의 변형으로 이벤트 채널 패턴이란것도 있다.

카테고리: etc

0개의 댓글

답글 남기기

Avatar placeholder

이메일은 공개되지 않습니다. 필수 입력창은 * 로 표시되어 있습니다.