티스토리 툴바

Daum
Tistory
로그인
블로그 이미지
카라크라스

Leon.Kim의 공부하는 블로그입니다. mail - kalaklas@gmail.com twitter - @kalaklas

Rss feed Tistory

Java/DesignPattern에 해당되는 글 4건

Java/DesignPattern 2011/02/08 11:20

inheritance and composition on Java

inheritance and composition on Java

 예전에 디자인 패턴 공부하기에 앞서 머리속에 잘 정리되어 있어야할 필수 요소로서
상속, 합성에 관한 정리가 필요했다.

GoF 에 보면 두번째 객체 지향 설계의 원칙으로
Favor object composition over class inheritance.

상속을 남발하지 말고 합성에 좀 더 의존하여 설계할 때 더 reusable하다는 결론을 내기위한 첫구문이었다;;(?)

아래처럼 정리했었는데 . . . GoF에 생성패턴, 행동패턴만 살펴 보고 거의 1년여째 미루고 있다;;;
공부 좀 해야하는데;


상속?
클래스 상속
- 클래스는 정의된 객체의 구현을 바탕으로 한다
 (코드와 내부 표현 구조를 공유하는 메커니즘)
인터페이스의 확장이 목적이 아니라 부모 클래스 구현의 재사용이 목적
->컴파일타임에 객체가 정적으로 정의됨
있는 클래스를 빨리 재활용해 새로운 클래스를 정의하려는 목적
 
인터페이스 상속
- 어떤 객체가 다른 객체 대신에 사용될 수 있는 경우를 지정하는 매커니즘
->런타임에 서브타입의 객체로 대체가 가능함(동적바인딩이 가능)

상속 ,합성: 객체 지향에서 기능의 재사용을 위해 구사하는 가장 대표적인 기법
 
상속 : 부모클래스의 구현을 상속받아 한 클래스의 구현을 정의하는것, White-box reuse(상속을 받으면 부모클래스의 내부가 자식에게 공개되므로)
합성 : 다른 객체를 여러 개 붙여서 새로운 기능 혹은 객체를 구성하는 것, Black-box reuse(내부가 공개되지 않은 상태에서 인터페이스를 통해서만 재
    사용되므로)
 
상속 
장점 : 컴파일 시점에 정적으로 클래스 구조가 정의되며, 부모 클래스의 일 부분만 재정의 가능하다.
단점 : 런타임에 상속받은 부모 클래스의 구현을 변경할수 없다
부모 클래스의 구현에 종속 적이므로 부모의 구현에 변경이 있을시 자식도 변경해야한다
 
합성 
장점 :
단점 :

'Java > DesignPattern' 카테고리의 다른 글

inheritance and composition on Java  (0) 2011/02/08
행동패턴 - 책임 연쇄 (chain of responsibility)  (0) 2010/11/25
Creational Pattern  (0) 2009/10/15
Fundamental Design Patterns  (0) 2009/08/19
design pattern, pattern in java
트랙백 0, 댓글 0
Java/DesignPattern 2010/11/25 02:28

행동패턴 - 책임 연쇄 (chain of responsibility)

행동패턴
어떤 처리의 책임을 어느 객체에 할당하는 것이 좋을지, 알고리즘을 어디에 정의하는 것이 좋은지 등을 다룬다.
객체간 교류의 방법을 다루는 카테고리다.


1. 책임 연쇄 (chain of responsibility)

의도
요청하는 객체와 처리하는 객체간 의존성을 최소화하자.

요청에 반응하여 처리하는 객체를 한정하지 않고 하나 이상의 객체에 부여해
요청 객체와 처리 객체 사이의 결합도를 낮춘다.

구현
>> 요청을 처리하는 핸들러(요청을 처리하는 다수의 처리 객체 chaining해주는 객체..)

1.요청 핸들러 객체로 클라이언트가 요청을 날린다
2.1번 처리 객체가 요청에 적합한 객체가 아니면
    2번 처리객체로 요청을 전달
3.2번 처리 객체가 요청에 적합한 객체가 아니면
   3번 처리 객체로 요청을 전달




소스는 내일 +_+
marine - fire
siegeTank - fire
Wraith - fire 


'Java > DesignPattern' 카테고리의 다른 글

inheritance and composition on Java  (0) 2011/02/08
행동패턴 - 책임 연쇄 (chain of responsibility)  (0) 2010/11/25
Creational Pattern  (0) 2009/10/15
Fundamental Design Patterns  (0) 2009/08/19
책임 연쇄 패턴
트랙백 0, 댓글 0
Java/DesignPattern 2009/10/15 14:00

Creational Pattern

GoF 의 디자인 패턴 그 첫번째 Creational Pattern 생성 패턴입니다.

Creational Pattern 관련 자료들 - 개요, 장단점, 확장성/재활용성 측면, 타 패턴과의 관계

-Abstract Factory
the Abstract Factory Pattern provides a way to encapsulate a group of individual factories.
다양한 구성 요소 별로 '객체의 집합'을 생성해야 할 때 유용하다. 이 패턴을 사용하여 상황에 알맞은 객체를 생성할 수 있다.

Abstract Factory Pattern은 상태에 따라 어떤 객체를 생성하여 반환할 지에 포커스가 맞춰진 패턴

Abstract Factory는 여러종류의 관련 객체들을 묶어서 생성할 숭 ㅣㅆ는 클래스 구현에 중점을 둔 패턴이다.


장점 : 한번 구현해둔 Factory간 교체가 쉬워 간단하게 Product군을 변경하여 갖을수 있다.
단점 : 팩토리에서 Product를 종류별로 일일이 생성해줘야 하는 단점 인터페이스 확장이 어렵다();


if(isWindows()){
WinButton btn = new WinButton();
WinScroll scr = . . . .
WinCheck chk = . . .
.
.
.
}else if(isOSX()){
MacButton btn = . . . . .
.
.
.
}else if(isLinux()){
.
.
.

}

이런 단점을 해결하고자 ~ *
Abstract Factory 패턴이 대두됏다.


Abstract Factory Pattern

구체적 클래스를 정의하지 않고도 서로 관련성이 있거나
독립적인 여러 객체의 군을 생성하기 위한 인터페이스 제공

 정의: 추상적인 부품을 조립해서 추상적인 제품을 만드는 추상적인 공장 같은 패턴
       : 클라이언트에서 구상 클래스를 지정하지 않으면서도 일군의 객체를 생성할 수 있도록 하는 패턴

활용:
1. 생성되고 구성되고 표현되는 방식과 무관하게 시스템을 독립적으로 만들고자 할 때 
2. 하나 이상의 제품군들 중 하나를 선택해서 시스템을 설정해야 하고 한번 구성한 제품을  다른 것으로 대체 가능할 때
3. 관련된 객체군을 함께 사용해서 시스템을 설계하고,  이 제품이 갖는 제약사항을 따라
야 할 때
4. 제품에 대한 클래스 라이브러리를 제공하고, 그들의 구현이 아닌 인터페이스를 표현하
고 싶을 때

결과:
       1.구체적인 클래스를 분리한다 – 
         추성클래스가 정의한 인터페이스를 통해서만 클라이언트 프로그램을 작성한다
       2. 제품군을 쉽게 대체할 수 있도록 한다
       3. 제품간의 일관성을 증진한다
       4. 새로운 종류의 제품을 제공하기 어렵다 – 
          새로운 제품에 대해 추상 팩토리를 확장하는 것이 어렵다


1. 이 패턴의 목적
    서로 관련성 있더나 독립적인 여러 객체의 군을 생성하기 위한 팩토리를 따로 구현 및 추가가 가능도록.

2. 이 패턴의 장점
    제품을 생성하는 실제 팩토리와 분리 시켜져서 서로 다른 상황별로 적당한 제품을 생산할 수 있는 다양한 팩토리를 자유롭게 확장 가능하다.

3. 이 패턴의 단점
    인터페이스의 확장이 어렵다. 

4. 이 패턴의 재사용성과 확장성에서의 측면
    팩토리의 확장과 교환이 쉽다     
    재활용적인 측면은 떨어진다 새로운 Product군의 추가에 대한 요구 사항이 생기면,
    AbstractFactory를 수정하고 그 녀석을 상속하는 모든 CocreteFactory에 대한 수정이
   필요하므로 확장성이 떨어진다고 볼수 있다.

5. 다른 생성 패턴과의 연관성
abstractFactory는 내부적으로 factoryMethod의 모습을 가지고 있다.
하지만 abstractFactory는 구성의 측면에서 객체를 생성하고 있고
factoryMethod는 상속의 측면에서 객체를 생성하고 있다.


AbstractFactory 클래스는 팩토리 메서드 패턴을 이용하여 구현된다.
========================================================================================================================================



-Builder
생성하는 방법과 표현하는 방법을 분리. 분리의 이유는 생성하는 방법이 복잡하기 때문임.

복잡한 인스턴스를 조립한다.

(생성)과정은 변하지 않는다.

공정, 부품(operation)만 변한다. -> 다른 표현을 만들 수 있게 한다.

Builder Pattern은 제품 생성 단계(절차, 방법)에 따라 생성된 객체들을 어떻게 조립하여 어떤 완성품(Product)을 생성하여 반환할 지에 포커스가 맞춰진 패턴

Abstract Factory와 Builder의 차이점 

Builder는 객체의 단계별 생성에 중점을 준다. 생성한 제품을 반환.

Abstract Factory 패턴은 제품의 유사군을 생성해달라고 요청만 한다. 즉시 각 부품을 반환.



Builder Pattern
복잡한 객체를 생성하는 방법과 표현하는 방법을 정의하는 클래스를 별도로 분리해 
서로 다른 표현이라도 이를 생성할 수 있는 동일한 구축 공정을 제공할 수 있다 

정의: 구조를 가진 인스턴스를 쌓아 올리는 패턴 : 제품을 여러 단계로 나눠서 만들 수 있도록 제품 생산 단계를 캡슐화하고 싶을때 사용

활용: 
     1. 복합 객체의 생성 알고리즘이 이를 합성하는 요소 객체들이 무엇인지 
        이들의 조립방법에 독립적일 때 – RTF reader
     2. 합성할 객체들의 표현이 서로 다르더라도 구축 공정이 이를 지원해야 할 때

결과: 
    1. 제품에 대한 내부 표현을 다양하게 변화할 수 있다
    2. 생성과 표현에 필요한 코드를 분리한다
    3. 복합객체를 생성하는 공정을 더 세밀히 나눌 수 있다 – 
       director의 buildPart()를 통해

관련 패턴: Abstract Factory 패턴이 복잡한 객체를 생성해야 하는 경우 Builder 패턴과 비슷한데,  Builder는 복잡한 객체의 단계별 생성에 중점을 두고, Abstract Factory는 제품의
유사군들이 존재하는 경우 유연한 설계에 중점을 둔다.
  Builder 패턴은 생성의 마지막 단계에서 생성한 제품을 반환하고 Abstract Factory 패턴에서는   만드는 즉시 제품을 반환한다. 이는 Abstract Factory 패턴에서 만드는 제품은 꼭
  모여야만 의미있는 것이 아니라 하나만으로도 의미가 있기 때문이다



Builder패턴의 유용성
복잡한 객체를 생성하는 데 있어 그 객체를 구성하는 부분 부분을 생성한 후 그것을 조합해도 객체의 생성이 가능할 때
서로 다른 표현 방식을 가지는 객체를 동일한 방식으로 생성하고 싶을 때

Builder 패턴의 장단점
객체의 내부 구조를 변경시킬 필요가 있을 경우 기존 소스코드에는 영향을 주지 않고, 새로운 하위 클래스를 추가 정의 할 수 있다.
Builder와 Director 클래스는 서로 독립적으로 수정되거나 재사용될 수 있다.
객체 생성 과정을 좀더 세밀하게 제어할 수 있다.
새로운 종류의 객체 생성을 추가하기는 쉬우나, 객체를 구성하는 각 부분들을 새롭게 추가하기는 어렵다.


구현 관련 사항
설계시 모든 하위 클래스들이 동일한 인터페이스를 가질 수 있도록 만든다.
Builder 패턴에 의해 생성되는 객체들은 서로 어떤 관계도 가질 필요가 없다 
⇒ 하위 클래스를 정의하는 이유가 서로 다른 종류의 객체를 생성하기 위함.
최상의 클래스가 반드시 Abstract Base Class로 정의될 필요가 없다.
예) Translator 클래스에서 각 멤버 함수에 대해 기본적인 구현을 해준다면,  
그 하위 클래스들이 멤버함수를 구현할 필요성이 줄어든다.


1. 이 패턴의 목적
 복합 객체의 생성 과정과 표현 방법을 분리함으로써 동일한 생성 공정이 서로 다른 표현을 만들 수 있게 한다.
복잡한 객체를 생성하는 방법과 표현하는 방법을 정의하는 클래스를 별도로 분리하여 서로 다른 표현이더라도 이를 생성할 수 있는 동일한 절차를 제공할수 있도록
(특정 instance들을 생성할 때 수행되어야 할 작업이 동일할 경우 적용될 수 있는 pattern)

2. 이 패턴의 장점
    객체 내부 표현을 다양하게 변화시킬수 있따 (builder만 교체하면..)
(생 성될 때(초기화 될 때) 동일한 과정을 수행해야 하는 서로 다른 Class의 instance에 대하여 통일된 생성방법(초기화 방법)을 제공할 수 있다는 것이다. (서로 동일한 상속관계를 가지지 않는 instance를 동일한 방법으로 생성할 수 있다!!!))
객체의 부분 부분을 생성하는 것과 그들을 조합해서 전체 객체를 생성하는 것이 서로 독립적으로 이루어질수 있다
서로 다른 펴현 방식을 가지는 객체를 동일한 방식으로 생성이 가능다.

3. 이 패턴의 단점
새로운 종류의 객체 생성을 추가하기는 쉬우나 객체를 구성하는 각 부분들을 새롭게 추가하는 것은 어렵다 ( AbstractBuilder의 인터페이스를 수정해야 하는 불상사가 생긴다.)

4. 이 패턴의 재사용성과 확장성에서의 측면
Build하는 부분이 캡슐화되서 (복잡한 생성 과정이..) 새로운 product가 추가되어도 쉽게 abstractBuilder를 상속하여 재사용성과 확장성이 좋다 build측면에서는 말이다.
하지만 build과정에 대한 추가적인 요구 사항이 생겻을 경우 abstractBuilder를 수정하고 그 녀석을 상속하는 모든 녀석을 수정해야할수도 있으므로 이런 측면에서의 확장성은 좀 떨어진다 볼수 있다.

5. 다른 생성 패턴과의 연관성
Builder 패턴도 AbstractFactory와 FactoryMethod와 비슷한 모습을 가지고 있다.(자기 자신 ConcreteBuilder와 관련있는 Product를 생성하여 공통된 모습대로 build하니깐..abstractFactory와 비슷하고 생성하는 부분을 서브 클래스가 전담하니깐 factoryMethod의 모습도 가지고 있다 볼수 있다.) 하지만, 

>> Factory Method는 어떤 객체를 생설할 때 여러 단계가 아닌 한단계로 서브 클래스에서 생성만 맡는다 이런점이 builder와 다른점 builder는 객체를 getResult하기 전까지 이래 저래 조합을 하고 return하는데 factoryMethod는 그렇지 않다.
위키피디아 : abstractFactory와 builder의 차이는 abstractFacatory는 생성 요청에 대해서 즉시 반환을 하는 반면에 Builder는 step by step으로 반환을 한다고 정의하고 있다


AbstractFactory와 Builder패턴은 비슷한 모습을 보인다.
하지만 빌터 패턴은 복잡한 객체의 단계별 생성에 중점을 둔 반면,
추상 팩토리 패턴은 제품의 유사군들이 존재할 때 유연한 설계를 하기 위하는데 중점을 둔다.
빌더 패턴은 생성의 마지막 단계에서 생성한 제품을 반환한다.
하지만 추상 팩토리 패턴은 만드는 즉시 반환한다.

========================================================================================================================================




- Factory Method

The factory method pattern is an object-oriented design pattern. Like other creational patterns,

 it deals with the problem of creating objects (products) without specifying the exact class of object that will be created           

팩토리 메소드 패턴은 객체를 생성하기 위한 인터페이스를 정의한다.
어떤 클래스의 인스턴스를 만들지는 서브 클래스에서 결정하게 되는것이다.

객체 생성을 처리하는 클래스를 캡슐화 시켜 놓으면 구현을 변경할때 여기저기 다 들어가서 고칠 필요없이 이 팩토리 메소드만 고치면 되기 때문에 . . .

단점 : Concrete Creator 의 종류가 많아지면 애플리케이션의 코드 수정이 불가피하다는 것


 Factory Method Pattern은 통일된 방법으로 객체를 만들고, 통일된 방법으로 생성된 객체를 조작하면서도, 각 생성된 객체들은 종류에 따라 자신만의 구현으로 동작할 수 있게 해주는 구조이다
단점 :  Factoty Method Pattern은 생성할 객체의 종류가 많아 질수록  그만큼의 하위 클래스를 정의해야 한다는 것이 부담이 될 수 있다


1. 이 패턴의 목적
   객체를 생성하고 동작하는 인터페이스를 정의하는데, 객체를 생성하는 역할은 서브 클래스에게 위임하는 패턴
팩토리 메소드 패턴을 이용하면 클래스의 인스턴스를 만드는 일을 서브클래스에게 맡기는것이다.

생산자 클래스 자체가 실제 생성될 인터페이스를 전혀 고려하지 않고 정의될수 있다.


2. 이 패턴의 장점
객체를 인스턴싱 하는 부분과 객체를 사용하는 부분을 분리하였으므로,
나중에 아무리 새로운 Product가 생기더라도 Creator의 수정 없이 확장이 가능하다.

어떤 객체를 생성할 것인지와는 무관하게 동일한 형태로 Creator의 프로그래밍이 가능하다는 점이다.


3. 이 패턴의 단점
    생성할 객체의 종류가 달라질 때 마다 새로운 서브 클래스를 정의해야 하기 때문에 프로덕트의 수대로 불필요하게 많은 서브 클래스가 정의되야 한다는 단점이 있다.


4. 이 패턴의 재사용성과 확장성에서의 측면
    서브클래스가 확장을 통하여 같은 타입의 어떠한 Product든지 인스턴싱하도록 정의가 가능하다.
동일 타입의 프로덕트를 생성하는 한 무한으로 서브 클래스의 확장이 가능하다. 
 Product가 아무리 생겨도 Creator의 변경 없이 이용이 가능하므로 재사용성 측면에서 보더라도 매우 큰 장점이 있다.
직접 생성자를 호출해서 객체를 생성하는 것보다 훨씬 유연하고 확장성이 있는 구조다

5. 다른 생성 패턴과의 연관성

========================================================================================================================================

이 세가지 패턴의 공통점은 객체를 실제로 생성하는 부분과 사용하는 부분을 따로 둠으로써

객체를 실제로 사용하는 Client 들이 쉽게 복잡한 객체를 사용 할 수 있게 해준다.



========================================================================================================================================

- Prototype
(Abstract Factory와 경쟁관계인 패턴이다 왜일까도 알아보자.)
Abstract Factory 나 Builder 패턴 등과는 달리 객체를 생성해주기 위해 별도의 클래스를 정의할 필요가 없다.
Prototype 패턴은 실행 시간(Run-Timr)에도 생성할 객체의 종류를 추가 또는 삭제할 수 있다.
(단) Clone( ) 멤버 함수를 구현해야 한다.

복사해서 인스턴스를 만든다.
※ 생성되는 과정이 복잡할 때 사용한다
견본 인스턴스를 사용하며 그걸 복제하여 새로운 객체를 생성한다.
제품의 생성, 합성, 표현 방법에 독립적인 제품을 만들때.
관련 패턴
Abstract Factory : prototype과는 경쟁적인 관계.

1. 이 패턴의 목적
    복잡한 객체를 인스턴싱하기 위한 목적에서 발생한 패턴이다.
어던 클래스의 인스턴스를 만드는 것이 자원과 시간을 많이 잡아 먹거나 복잡한 경우에 프로토타입 패턴이 적당하다.


2. 이 패턴의 장점
    클라이언트는 새로운 인스턴스를 만드는 복잡한 과정을 몰라도 된다.
    클라이언트에서는 구체적인 형식을 모르는 아무리 복잡한 객체 더라도 쉽게 객체를 생설할 수 있다.
    상황에 따라서 객체를 새로 생성하는 것 보다 객체를 복사하는 것이 더 효율적일 수 있다.

3. 이 패턴의 단점
    shallow Copy 단순카피 피상적카피: 레퍼턴스만 카피 하는 것 자바에서 clone()는 shallow Copy이다
    Deep Copy 깊은 카피 : 실제 값 까지 복사 하는 것


4. 이 패턴의 재사용성과 확장성에서의 측면
    

5. 다른 생성 패턴과의 연관성


========================================================================================================================================

- Singleton
클래스의 인스턴스는 오직 하나임을 보장하며 이 인스턴스에 접근할 수 있는 방법을 제공.
클래스에서 만들 수 있는 인스턴스가 오직 하나(혹은 원하는 만큼만)일 경우 이에 대한 접근을 어디에서든지 하나로만 통일하여 제공한다.
========================================================================================================================================



'Java > DesignPattern' 카테고리의 다른 글

inheritance and composition on Java  (0) 2011/02/08
행동패턴 - 책임 연쇄 (chain of responsibility)  (0) 2010/11/25
Creational Pattern  (0) 2009/10/15
Fundamental Design Patterns  (0) 2009/08/19
트랙백 0, 댓글 0
Java/DesignPattern 2009/08/19 00:05

Fundamental Design Patterns

Fundamental Design Patterns

-Delegation Pattern
 Delegation이라는 영어 단어 자체의 뜻이 "위임" 이라는 것을 고려해보면 Delegation은 어떤 동작을 자신이 직접 수행하지 않고 다른 것 (method, object, etc)에게 위임한다는 것이다.
객체가 할 행동을 객체 자신을 수정하지 않고 Delegation을 수정 (또는 재 정의) 함으로써 가능하다 (확장성).
  • 이 것은 프로그램이 거대해지고 복잡해질 수록 효과를 발휘할 것이다.
  • 또한 동적으로 객체의 행위를 변경하기 용이할 것이다.
  • 또한 프로그램이 fron-end가 아닌 framework이고 API interface를 제공하는 입장이라면 Delegation은 단순히 효과 적인 기법이 아닌 확장 (테스팅 포함)을 위한 필수 조건일 수도 있다. 
 

interface I {
void f();
void g();
}

class A implements I {
public void f() { System.out.println("A: doing f()"); }
public void g() { System.out.println("A: doing g()"); }
}

class B implements I {
public void f() { System.out.println("B: doing f()"); }
public void g() { System.out.println("B: doing g()"); }
}

class C implements I {
// delegation
I i = new A();

public void f() { i.f(); }
public void g() { i.g(); }

// normal attributes
void toA() { i = new A(); }
void toB() { i = new B(); }
}


public class Main {
public static void main(String[] args) {
C c = new C();
c.f(); // output: A: doing f()
c.g(); // output: A: doing g()
c.toB();
c.f(); // output: B: doing f()
c.g(); // output: B: doing g()
}
}
출처 :> http://en.wikipedia.org/wiki/Delegation_pattern 위키피디아



-Immutable Pattern
이뮤터블 패턴의 개념은 한마디로 표현할 수 있다. 한번 만든 객체는 변형하지 않으며, 변형이 발생할 때는 새로운 객체를 만든다는 것. 
Java의 String객체는 String이 변형될때 새로인 객체가 만들어진다.

Example>
String a = "a";
String b = "b";

String ab = a+b;

위의 경우 ab객체는 a와 b 객체가 합쳐진 객체가 아니라, 새로 생성된 객체이다.

String은 Java에서의 대표적인 Immutable Object이다. 
한번 인스턴싱된 객체는 변형되지 않으며, 변형이 발생할 때는 새로운 객체가 인스턴싱된다.

class Cart {


   private final List items;


 


   public Cart(List items) { this.items = items; }


 


   public List getItems() { return items; }


   public int total() { /* return sum of the prices */ }


}


class ImmutableCart {


   private final List items;


 


   public ImmutableCart(List items) {


     this.items = Collections.unmodifiableList(new ArrayList(items));


   }


 


   public List getItems() {


     return items;


   }


   public int total() { /* return sum of the prices */ }


 }

출처 : http://en.wikipedia.org/wiki/Immutable_pattern 위키피디아


- Marker Interface
*What is Maker Interface?
Serializable 인터페이스 같이 구현이 필요없는(아무것도 구현하지 않을 인터페이스) 인터페이스를 Maker Interface라고 한다.
(Serializable interface? >> )

말그대로 표시해주는 역할을 하는 interface를 implements한다.
내가 정한 표시로 내가 원하는 클래스를 구별할수 있다.


*Why Use Maker Interface?
적절한 예시가 될런지 모르겠지만;;;;

public interface Korea{}
public interface Japan{}
public interface China{}

 이렇게 세 종류의 구현이 필요없는 인터페이스가 세개 있다고 했을 때,

여러종류의 Product Object들이 있을때 (자동차, 자전거, 세탁기등등등 )
각각의 생산 국가를 마킹하기 위해 

public Vehicle implements Korea{.........}
pubic Bycycle implements China{.........}
요런식으로 . . . 마킹을 한다.

요걸 Maker Interface Pattern이라 한다

In java language programming, interfaces with no methods are known as marker interfaces. Marker interfaces are Serializable, Clonable, SingleThreadModel, Event listener. Marker Interfaces are implemented by the classes or their super classes in order to add some functionality.

e.g.  Suppose you want to persist (save) the state of an object then you have to implement the Serializable interface otherwise the compiler will throw an error. To make more clearly understand the concept of marker interface you should go through one more example.  

Suppose the interface Clonable is neither implemented by a class named Myclass nor it's any super class, then a call to the method clone() on Myclass's object will give an error. This means, to add this functionality one should implement the Clonable interface. While the Clonable is an empty interface but it provides an important functionality.




- Proxy Pattern
Proxy의 사전적 의미는 대리, 위임이다.


import java.util.*;


 


interface Image {


    public void displayImage();


}


 


//on System A 


class RealImage implements Image {


    private String filename;


    public RealImage(String filename) { 


        this.filename = filename;


        loadImageFromDisk();


    }


 


    private void loadImageFromDisk() {


        System.out.println("Loading   " + filename);


    }


 


    public void displayImage() { 


        System.out.println("Displaying " + filename); 


    }


}


 


//on System B 


class ProxyImage implements Image {


    private String filename;


    private Image image;


 


    public ProxyImage(String filename) { 


        this.filename = filename; 


    }


    public void displayImage() {


        image = new RealImage(filename);


        image.displayImage();


    }


}


 


class ProxyExample {


    public static void main(String[] args) {


        Image image1 = new ProxyImage("HiRes_10MB_Photo1");


        Image image2 = new ProxyImage("HiRes_10MB_Photo2");     


 


        image1.displayImage(); // loading necessary


        image2.displayImage(); // loading necessary


    }


}

출처 : http://en.wikipedia.org/wiki/Proxy_pattern 위키피디아 

>>Proxy패턴은 Decorator패턴과 유사하여 혼동되기도 합니다.
하지만 두가지 패턴은 서로 다른 목적을 가진 패턴들입니다.

*Proxy패턴은 기존에 구현되어있는 기능(객체)에 보다 효율적으로 접근, 원격 제어, 접근 권한 제어하는것 등이 목적입니다.
*Decorator패턴은 구현되어 있는 기능에 새로운 기능의 추가를 쉽게하는 것이 주요 목적입니다.


'Java > DesignPattern' 카테고리의 다른 글

inheritance and composition on Java  (0) 2011/02/08
행동패턴 - 책임 연쇄 (chain of responsibility)  (0) 2010/11/25
Creational Pattern  (0) 2009/10/15
Fundamental Design Patterns  (0) 2009/08/19
delegation, Immutable, Java, marker interface, Pattern, proxy pattern, 디자인패턴
트랙백 0, 댓글 0
1
TOTAL 16,072 TODAY 60