디자인패턴
: 특정 환경에서 반복적으로 발생하는 설계문제들에 대한 일반적인 해결책
이미 많은 검증을 거쳤기 때문에 특정문제에 대한 좋은 해답
설계문제, 제안된 해결책, 그리고 설계문제 또는 해결책에 영향을 미칠 다른 요인들(factor)에 대한 정형화된 접근방법(formal approach)을 사용한다
즉,
S/W설계시 특정 문제(또는 환경)가 반복적으로 발생하고
이를 해결하기 위한 해결책이 일반적으로 잘 알려져 있으며
간결하고 명확하고 검증된 것
[ Funcdamental Design Pattern ]
- Deligation
: 상속이라는 방법으로 수시로 변하는 객체를 표현하기에 부적절할때 사용
아래와 같이 클래스안에서 다른 클래스를 생성하여 속성이용.
class AAA{
BBB b = new BBB();
checkBBB(){
b.CheckB();
}
}
- interface
: interface를 deligation해서 사용한 클래스에서는 인터페이스를 구현한 클래스만 바꾸어주면 최소한의 코드변경으로 기능을 수정할수 있다.
"어떤 사람이 새의 다리에 편지를 묶어서 날리기" 라는 문제를 풀이해보면
class 어떤 사람{
새 a = new 참새();
a.다리에 편지 묶어 날리기();
}
interface 새{
다리에 편지 묶어 날리기();
}
class 참새 implements 새{
다리에 편지 묶어 날리기(){
//우째우째 구현되어 있음.
}
}
class 씨방새 implements 새{
다리에 편지 묶어 날리기(){
//우째우째 구현되어 있음.
}
}
씨방새의 다리에 편지를 묶어 날리면 으로 바꾸믄 씨방새 클래스를 이용.
- Marker Interface
: 의미의 재확인용
interface flyable{
}
class 참새 extends 새 implements flyable{
}
class 닭 extends 새 {
}
class 새장{
참새 a = new 참새();
닭 b = new 닭();
날라라(a);
날라라(b);
public 날라라(새 bird){
if( bird == null || bird instanceof flyable)
너는 진짜 날줄아는구나! 날라가라();
else
너는 날개는 있지만 몰 나는구나! 에잇! 바보야!();
}
}
이와 같이 날줄아는 새는 flyable 이라고 마킹해 놓코 나중에 이 넘을 체크해서 진짜 날 수 있는 새을 구분해 낸다.
- Proxy
: 한 과정을 하기전에 다른 과정이 거치거나, 그 과정을 다른 객체가 하게 할경우
deligation에 deligation을 하는 경우가 Proxy
[ Factory Method ]
: 객체생성을 new로 하는게 아니라 객체생성하는 메소드로 대신하며 내부적으로 인터페이스로만 오브젝트를 생성한다.
"닭이 계란을 낳는다는것을 새가 알을 낳는다는것으로 표현"
"생성될 클래스의 오브젝트가 어떤것일지 예상하지 못할때나 생성할 오브젝트를 서브클래스에서 결정해야할때 유용하다
"
즉 한가지 정해진 결과에 대해 예측하기 힘든 여러가지의 경우를 두고 , 한곳에서 집중적으로 관리해야하는 경우.[마린생각..ㅠ.ㅠ]
abstract class Creator
{
abstract public Product FactoryMethod();
// 오퍼레이션을 추상 클래스내에서 정의
// Ref: Template Method 패턴
public void AnOperation()
{Product aProduct = FactoryMethod();
System.out.println(getClass() + " is a Creator of " + aProduct.getClass());}
}
추상클래스내에서 Abstract FactoryMethod()를 정의하고, AnOperation을 구현, 이를 이용하여 각 서브클래스들을 creator형으로 생성하여 AnOperation()을 호출 -> product 생성.
- Product : 팩토리 메소드가 생성하는 오브젝트를 위한 인터페이스를 정의 한다. (알)
- ConcreateProduct : Product 인터페이스를 구현. (계란)
- CreationRequestor(Creator) : factory method를 선언하고, Product 타입의 객체를 리턴한다. (새)
- FactoryIF : CreationRequestor 대신해 product객체를 생성할 때는 이 인터페이스를 구현해야한다. (낳다)
- Factory : ConcreateProduct의 인스턴스를 리턴하는 factory method를 override한다. (알과 계란연결)
[ Abstract Factory ]
: Abstact Factory pattern은 Factory Method pattern과 유사하다.
하지만 이 두 패턴의 가장 큰 차이점은
Factory Method pattern - 상속과 원하는 오브젝트의 인스턴스를 생성하는 서브클래스에 의존
Abstract Factroy pattern - 오브젝트의 인스턴스하는 것을 특정 클래스(ConcreateFactory)가 도 맡아서 처리.
그래서 abstract factory pattern에서는
관련된 오브젝트의 family를 생성해내는 인터페이스를 제공해 준다.
abstract class AbstractProductA
{
abstract public void left();
abstract public void right();
}
abstract class AbstractProductB
{
abstract public void top();
abstract public void buttom();
}
실제로 delegate된 오브젝트는 인스턴스화를 위해서 주로 factory method가 이용된다.
"시스템에 독립적인 소프트웨어를 만들어야 될 때나 생성해야할 오브젝트의 클래스를 예상할 수 없는 경우, 여러 객체 그룹중에 단 하나의 패밀리군을 사용해야할 때, 일정한 연관성을 유지해야하는 객체 그룹에서 그런 제약을 따라야 할 때등에 사용될 수 있다."
즉 같은 성격의 객체그룹이 여러개 있는 반면, 어느 객체그룹을 사용해야 할지 모를때 사용 [마린생각]
abstract class AbstractFactory
{
abstract public AbstractProductA CreateProductA();
abstract public AbstractProductB CreateProductB();
}
[ Singleton ]
: 클래스의 인스턴스를 오직 하나만 생성 되도록 하고, 그 클래스의 인스턴스를 사용하는 모든 오브젝트들은 같은 인스턴스를 사용하게금 글로벌 포인트(전역변수 같은거)를 제공하는 패턴이다
둘 이상의 인스턴스가 만들어지지 않게 하기 위해 생성자를 private로 해서 클라이언트는, Singleton의 인스턴스를 자유롭게 만들 수 없게 한다. 또한 static 메소드(클래스메소드: 클래스의 모든객체에서 공유한다)를 하나 만들어 오직 그 메소드만을 통해서만 생성자에 접근할 수 있도록 한다.
시스템 자원중에 (프린트, 시리얼포트, 사운드카드) 디바이스 드라이버 오브젝트 같은 경우 여러 개의 오브젝트에서 사용하면 문제가 발생할 수 있다
[ Builder ]
:
builder 패턴은 클라이언트 오브젝트가 간단한 세팅만으로도, 복잡한 오브젝트를 생성할 수 있게 하며, 오브젝트의 생성 순서를 생성 수단과 분리하기 위한 패턴이다. 어떤데이터에 따라 화면 구성을 다르게 해야하는 상황이나, 복잡한 객체를 생성하는 알고리즘이 구성 객체가 연동된 방식과 상관없이 일정한 순서,논리로 적용되어야 하는 상화에서 응용가능하다.
다시 말하면, 같은 생성자로 다른 구조의 결과값을 가진 객체를 생성해야할때 쓰인다.
Director는, 생성 순서를 알고 있는 클래스이고, Builder는 오브젝트를 생성하는 클래스이다. Director는 용도에 따라 정의된 Builder를 이용한다
class Director
{
Builder _builder;
public Director(Builder aBuilder)
{_builder = aBuilder;
}
public void Construct()
{
//이부분은 Builder 클래스에서 순서가 메소드마다 정의 되어있다.
_builder.BuildFirstName();
_builder.BuildMiddleName();
_builder.BuildLastName();}
}
abstract class Builder
{
public void BuildFirstName()
{
}
public void BuildLastName()
{
}
public void BuildMiddleName()
{
}
}
[ Prototype ]
:
복제에 의해 자신의 인스턴스를 생성해낼수 있는 객체에 쓰인다.
새로운 인스턴스를 생성하는 것이 비용이 많이 들 때 새로 객체의 인스턴스를 만들기 보다 존재하는 클래스를 복제(clone) 하거나 복사(copy)하는 패턴이다. 이 패턴의 장점은, 추상 클래스만을 취급하는 클라이언트가, 그 클래스의 콘크리트 클래스를 모르고도, 속성을 계승한 새로운 클래스를 생성할 수가 있다고 하는
점이다
abstract class Prototype
{
abstract public Prototype Clone();
abstract public void DispID();
abstract public void ChangeID();
}
[ Object Pool ]
:
ObjectPool 패턴은 오브젝트를 만드는데 너무 많은 비용을 지불해야할 때나, 제한된 오브젝트 수만을 만들어야 할 때 사용되는 패턴으로, 보통 오브젝트를 어느 정도 미리 만들어 놓고 필요할 때 사용하고, 다 사용하면 반환해 다른 클라이언트가 사용할 수 있게금 풀을 사용하는 것이다.
좋은 예로 DBPool , 쓰레드 풀, 등을 들 수 있겠다. 풀에 관한 추상적인 예를 들어보도록 하겠다. 사과장사를 하는데. 진열대에 올려 놓고 파는 것하고, 손님이 사과를 살 때마다 창고에 가서 사과하나를 가져 오는 것을 생각해 보자. 전자의 경우 손님이 사과사는데 아무 문제없다. 사과가 진열대에 있으면 보고 바로 돈주고 사는 것이다. 후자의 경우 주인아저씨 보고 사과 팔아요라고 물어보고 아저씨는 창고에 있으니까 잠시 기다려라고 하고 가져와서 파는 것과 같다. 여기서 진열대를 풀(Pool)이라고 할 수 있다.
[ Adapter ]
:
Adapter 패턴은 기존의 클래스를 수정해서 필요한 클래스를 만든다.
이패턴에 의해 필요한 메소드를 재빨리 만들수 있다. 만약 버그가 발생하더라도 기존의
클래스(Adaptee 역할)에는 버그가 없기 때문에 , Adapter 역할의 클래스를 중점적으로 조사
하기만 하면 되니까 프로그램 체크가 쉬워짐.
- Adapter 패턴은 기존의 클래스에는 전혀 손을 대지 않고 목표로 한 인터페이스(API)
에 맞추는 것이다.
- 버전업과 호환성이 용이하다.
- Adaptee 역할과 Target 역할의 기능이 너무 동떨어져 있는경우에는 Adapter 패턴을 사용할수 없다
클래스를 사용한 Adapter Pattern
public class Adapterpattern{
public static void main(String args[]){
Print p = new PrintBanner("Hello");
p.printWeak();
p.printStrong();
}
}
class Banner{
private String string;
public Banner(String string){
this.string = string;
}
public void showWithParen(){
System.out.println("(" + string + ")");
}
public void showWithAster(){
System.out.println("*" + string + "*");
}
}
interface Print{
public abstract void printWeak();
public abstract void printStrong();
}
class PrintBanner extends Banner implements Print{
public PrintBanner(String string){
super(string);
}
public void printWeak(){
showWithParen();
}
public void printStrong(){
showWithAster();
}
}
[ Iterator ]
:
Iterator는 오브젝트들을 가지고 있는 집합인 Collection(Container라고도 함) 의 요소를 순서적으로 접근하는 패턴이다. 이는 외적으로 객체가 어떤 식으로 구성되어 있는지에 대한 내부구조를 노출하지 않고 collection을 이용해 접근하는 것이다. Collection의 예로 Linked List 나 Hash Table을 들 수 있다. DB로 치면 Cursor가 이런 일을 한다고 생각하면 되겠다.
Iterator 패턴을 사용하면 다음과 같은 장점이 있다.
for (Iterator i = ppactions.keySet().iterator(); i.hasNext();){
String key = (String) i.next();
PPAction action = (PPAction) ppactions.get(key);
}
[ MVC ( Model - View - Controller) ]
:
Model - Strores the application state
Response to data requests
Encapsulates business logic
View - Renders the UI
Requests data from the Model
Sends events to the Controller
Controller - Handles routing to the correct page
Maps UI Data changes to model ( Data & Transactions)
Front-Controller (Facade)
: 마스터 Controller와 Sub 하위 Controller가 존재하는 패턴.
마스터 Controller가 하위 Controller에게 dispatch해준다.
[/HTML]
