happyness

데코레이터 패턴은 새로 상속 받아 클래스를 생성하는 것 없이 개별의 객체들의 행위를 수정할 수 있는 방법을 제공. 8개의 객체들을 가지는 프로그램이 있는 경우.
그러나 그 중 3개는 추가적인 속성이 필요함. 이러한 객체들의 각각에 대하여 상속받아 클래스를 생성할 수도 있고, 많은 경우에 이것은 완벽하게 받아 들일 수 있는 해결책일 수 있음. 그러나, 이 세 객체의 각각이 다른 수정을 요구한다면, 이것은 세 개의 상속 받은 클래스를 생성하는 것을 의미. 게다가, 클래스들 중에 하나가 다른 두개 클래스의 특성을 가지고 있다면, 혼란스럽고 불필요한 클래스를 생성.

1. 의도
프로그램 실행 중에 특정 객체에게 추가적인 책임들을 동적으로 할당할 수 있음. 기능을 확장할 때 기존 클래스를 상속 받지 않고 문제를 해결할 때 사용.

2. 고려해야 할 사항
상속을 이용해 기능 확장을 할 경우 다음과 같은 문제 발생

• 서브 클래스는 슈퍼 클래스에서 필요하지 않은 기능까지 상속 받기 때문에, 서브 클래스는 비대해지고 응집력이 떨어지게 됨.
• 복사-붙이기 방식을 이용해 같은 코드를 여러 클래스에 추가할 경우, 시스템에 어떤 변동사항이 발생했을 때 관리하가 어려워짐.

따라서 해결방안을 제시할 때 다음과 같은 사항을 고려

• 클래스의 기능이 간단한 방법을 이용해 확장될 수 있어야 함.
• 클래스에 필요한 기능을 다이나믹 하게 추가하거나 또는 제거할 수 있어야 함.
• 클래스의 응집력을 높여야 하고 코드 중복을 최소화해야 함.

3. 구조

4. 자바 프로그래밍 언어에서의 사용 예

• java.io 패키지에서 Decorator 패턴이 사용됨.
• FileInputStream, ByteArrayInputStream, 기타 다른 클래스들은 InputStream 추상
  클래스를 상속 받음. 게다가, 입력 소스가 무엇이든 상관없이 input stream에
  기능을 추가할 수 있는 클래스는 InputStream 추상 클래스를 확장 받으면 됨.
• BufferedInputStream, DataInputStream 클래스와 같은 추가적인 기능을 정의하고 있는
  클래스들이 “데코레이터(Decorator)”들 임.
• 데코레이터(Decorator)가 제공하는 메소드가 호출되었을 때, 이들이 장식하고 있는
  클래스들의 대응되는 메소드를 호출.

5. 결과

• 장점
  단순한 상속보다는 설계의 융통성을 증대시킬 수 있음. Decorator 패턴은 객체에 새로운 행위를 추가할 수 잇는 가장 효과적인 방법임. Decorator를 사용하면, 테코리이터를 개체와 연결하거나 분리하는 작업을 통해 새로운 책임을 추가하거나 삭제하는 일이 런타임 시에 가능해짐. 그러나 상속은 코드상에서, 즉, 정적으로 새로운 클래스를 추가해야만 추가적인 행위를 정의할 수 있는 방법임.
  지금 예상하지 못한 특성들을 한꺼번에 다 개발하기 위해 고민하고 노력하기보다는 지속적으로 Decorator 객체를 통해 발겨하지 못하고 누락된 서비스들을 추가 할 수 있음.
• 단점
  장식의 역할을 수행하는 객체와 장식을 받게 되는 역할을 수행하는 객체는 서로 다름. 그래서 식별자가 문제 될 수 있음.
  테코레이터를 사용함으로써 작은 규모의 객체들을 많이 생성하게 됨에 따라, 수행 속도가 약간 떨어질 수 있음.
  

happyness Programming/J2EE Patterns Decorator, Structural, 구조패턴

종종 프로그래머들은 독립적인 객체나 객체들의 수집으로 표현될 수 있는 객체를 갖는 컴포넌트로 이루어진 시스템을 개발. 컴포지트 패턴은 위의 두 가지 경우를  조정하기 위하여 계획되어진다. 컴포지트 패턴은 부분-전체의 상속을 만들거나 트리로 데이터를 표현하는 걸 만들려 할 때 사용되어 질 수 있음. 요약해서, 하나의 컴포지트는 객체들의 수집. 트리 목록에서, 어떤 객체들은 추가적인 가지들을 가지는 노드일 수도 있고 어떤것들은 잎들일 수도 있음.

1. 의도
Composite 패턴을 적용하면 전체-부분을 표현하기 위해 객체를 트리 구조로 묶을 수 있음. 클라이언트 코드는 각 개별적인 객체(부분)와 다른 객체를 포함하는 객체(전체)를 동일한 인터페이스를 통해 사용할 수 있음.

2. 고려해야 할 사항

• 재귀적 트리 구조는 트리의 깊이가 깊은 계층구조를 형성할 수 있음.
• 합섭 오브젝트가 제공하는 오퍼레이션 중 일부는 콤포넌트 부분과 다른 합성 오브젝트에 전달되어야 함.
• 클라이언트와 결합도를 줄이기 위해, 종종 합성 오브젝트(전체)와 부분 오브젝트간의 차이점을 무시해야 함. 다시 말해서, CASE 문 사용을 피해야 함.
• 합성 오브젝트(전체)와 부분 오브젝트간 차이점이 항상 투명하게 나타나는 것은 아님. 때때로, 부분 오브젝트에서 필요로 하는 액션이 합성 오브젝트에서는 의미가 없거나, 합성 오브젝트에서 필요로 하는 액션이 부분 오브젝트에서는 의미가 없을 수 있음.

3. 구조

Clerk.java (Language : java)

1. public class Clerk implements Employee {
2.    private double basePayRate;
3.    private double invidualBonus;
4.    private int overtimeHours;
5.  
6.    public double calculateDeptPay() {
7.       return calculatePay();
8.    }
9.  
10.    public double calculatePay() {
11.       double pay = // ...
12.       return pay;
13.    }
14. }

Manager.java (Language : java)

1. public class Manager implements Employee {
2.    private Employee subordinates[];
3.  
4.    public void addSubordinate(Employee e) {
5.       // ... add e to the subordinates array
6.    }
7.  
8.    public double calculateDeptPay() {
9.       double totalPay = calculatePay();
10.       for (int i=0; i<subordinates.length; i++) {
11.          totalPay += subordinates[i].calculateDeptPay();
12.       }
13.       return tatalPay();
14.    }
15.  
16.    public double calculatePay() {
17.       double pay = // ...
18.    }
19.  
20.    // ...
21. }

4. 자바 프로그래밍 언어에서의 사용 예

• Composite 패턴은 J2SE 플랫폼에서 Abstract Window Toolkit(AWT)에서 사용
• AWT에서, Container는 다른 콤포넌트를 포함할 수 있는 콤포넌트 임. 예를 들어,
  Window 클래스는 Container 클래스의 서브클래스로 Button과 List 오브젝과 같은
  콤포넌트를 포함할 수 있음.
  

5. 결과

• 장점
  클라이언트 코드는 각 개별적인 객체(부분)과 다른 객체를 포함하는 객체(전체)를 동일한 인터페이스를 통해 사용할 수 있음.
  사용자는 사용할 오브젝트가 합성 오브젝트인지 부분 오브젝트인지 모르고 개발할 수 있기 때문에 사용자 코드에서 CASE 문을 줄일 수 있음.
  Composite 패턴은 전체 - 부분을 포현하기 위해 객체들을 트리 구조를 형성하고 있기 때문에 확장이 용이.
• 단점
  콤포넌트 인터페이스는 합성 오브젝트에서 필요하지만 부분 오브젝트는 필요헚는 메소드를 정의해야 함. 따라서 인터페이스의 응집력이 떨어짐.
  

happyness Programming/J2EE Patterns Composite, Structural, 구조패턴

어댑터 패턴은 어떤 클래스의 인터페이스 프로그래밍을 다른 클래스로 변환할 때 사용. 우리는 어댑터를 하나의 프로그램에서 함께 작업하는 클래스간에 서로 관련성이 없게 하고자 할 때 사용. 어댑터의 개념은 그러므로 간단; 우리는 요구되는 인터페이스를 갖는 클래스를 작성하고 다른 인터페이스를 갖는 클래스와 통신할 수 있게 함.
 어댑터를 구현하는 방법에는 상속에 의한 방법과 객체 조합에 의한 방법이 있음. 첫번째 경우에서, 우리는  상속 받는 새로운 클래스를 만들고 요구되는 인터페이스에 매치되는 상속받은 새로운 클래스를 만들기 위해 필요로 하는 메소드를 추가. 다른 방법은 새로운 클래스 내부에 원본의 클래스를 포함하는 방법이고 새로운 클래스 내부에서 호출되는 변환하기 위한 메소드를 생성.

1. 의도
클래스의 인터페이스를 클라이언트가 필요로 하는 형태의 인터페이스로 벼환. 어댑터 패턴은 서로 일치하지 않는 인터페이스를 갖는 클래스들을 함깨 동작 시킴.

2. 고려해야 할 사항

• 현재 사용하고 있는 콤포넌트가 제공하고 인터페이스와 다른 형태의 인터페이를 제공하고 있는 콤포넌트를 사용하고자 하는 경우 클러이언트쪽을 수정할 경우 클라이언트를 더 복잡하게 만들 수 있음.
• 또한, 이 클래스가 폴리모피즘을 이용해 다른 클래스를 사용하고 잇을 때 현재 사용하고 잇는 인터페이스를 다른 인터페이스를 사용하도록 수정할 경우 문제가 발생할 수 있음.
• 사용하고자 하는 클래스가 제공하는 잇는 인터페이스가 원하는 형태의 인터페이스가 아닐 경우, 이 클래스를 수정할 수있음. 그러나, 이 클래스가 다른 위치에서 사용되고 있을 경우, 이것은 동일한 기능을 제공하지만 제공하는 인터페이스가 다른 두가 버전의 클래스를 관리해야 함.
• 복사-붙이기 방식을 이용 또는 많은 양의 코드를 재작성 하는 방식으로 기존 코드를 재사용하는 것은 좋은 방법이 아니고, 유지보수 비용이 증가하는 문제가 발생.

3. 구조

Library3SearchEngineAdapter.java (Object Adapter를 이용한 해결) (Language : java)

1. import java.util.ArrayList;
2.  
3. public class Library3SearchEngineAdapter implements Searchable {
4.    private Library3SearchEngine adaptee = new Library3SearchEngine();
5.    public ArrayList searchByAuthor(String author) {
6.       // “작가”를 기준으로 한 검색 수행동작을 구현합니다.
7.       return results;
8.    }
9.  
10.    public ArrayList searchByCallNumber(String callNum) {
11.       return adaptee.searchByCallNumber(callNum);
12.    }
13.  
14.    public ArrayList searchByTitle(String title) {
15.       char t[] = title.toCharArray();
16.       return adaptee.titleSearch(t);
17.    }
18. }

4. 자바 프로그래밍 언어에서의 사용 예

• Java API는 당장 사용할 수 있는 어떠한 고용 어뎁터 객체도 포함하지 않고 있음. 다만, java.awt.event.WindowAdapter와 같은 직접적으로 시용되기 보다는 간접적으로 상속받아 사용될 수 있게 하기위한 클래스를 포함하고 있음.

5. 결과

• 장점
  클라이언트 클래스는 추가 수정 없이 다른 인터페이스를 제공하는 콤포넌트를 사용할 수 있음.
  Adaptee 클래스는 수정되지 않음.
  Class Adapter 전략 사용시, 하나의 오브젝트만 사용하기 때문에, 또 다른 객체를 생성하거나 클라이언트의 요청을 다른 객체쪽으로 전달하는 것과 같은 동작이 필요없음.
• 담점
  오브젝트를 추가적으로 생성해야함.
  클라이언트의 모든 요청을 다른 객체에게 던달해야 하기 때문에, 약간 오베헤드가 증가.
  Object Adapter 전략 사용시 Adaptee 클래스이 행위를 재정의하는 것은 어려움.
  자바 프로그래밍 언어에서는 단일 상속만 가능. 따라서 Class Adapter 전략 사용이 어려울 수 있음.
  

happyness Programming/J2EE Patterns Adapter, Structural, 구조패턴

Proxy 패턴은 간단한 객체로 복잡한 객체를 표현하고자 할 때 사용되어짐. 만약 어떤 객체를 생성하는 것이 시간적으로나 컴퓨터 자원적으로 비용이 많이 든다면 , Proxy는 실제적인 객체를 필요로 할 때까지 객체 생성을 연기. 일반적으로 Proxy는 표현하고자 하는 객체와 같은 메소드를 갖고, 일단 객체가 로드되면, 그것은 Proxy에서 실제적인 객체의 메소드로 바뀌게 됨.

Proxy 가 유용하게 사용되어 질 수 있는 유용한 경우

• 커다란 이미지와 같은 객체가 로드하는데 시간이 많이 걸린다면 Proxy가 유용.
• 원격 머신에 객체가 있고 그 객체를 네트워크를 통하여 로드하는데 느릴 수 있고, 특히나 로드하는 동안 네트워크 상태가 절정이라면 Proxy가 유용.
• 객체가 바로 접근하는 것이 제한되어 있다면 Proxy는 사용자의 접근허용을 검증할 수 있음.

1. 의도
다른 객체에 접근하기 위해 중간 대리인 역할을 하는 객체를 제공

2. 고려해야 할 사항

• 리모트 오브젝트
  클래스가 리모트 클래스를 억세스하기 위해서는 주기능과 상관없는 네트워크 관련 코드를 작성해야 함. 이와 같이 네트워크 관련 코드를 클라이언트와 리모트 클래스에 정의할 경우 응집력 및 재사용성이 떨어지고, 유지관리하기가 어려움.
• 자원을 많이 필요로 하는 오브젝트
  이지지와 같은 테이터를 표현하기 위해 클래스가 많은 메모리를 사용할 경우, 해당 클래스가 실질적으로 필요할 때까지 객체를 생성하지 말아야 함.
• 억세스를 제안해야 할 오브젝트
  어떤 자격을 가지고 있을 경우에 클래스를 억세스할 수 있도록 할 경우, 클래스를 보호하기 위한 보안 관련 코드는 보호하고자 하는 클래스 내에 정의하지 말아야 함. 보안 관련 코드를 직접 보호되어야 할 클래스 내에 정의할 경우 클래스의 응집력을 떨어지게 됨.

3. 구조

RoomTtpeImage.java (Language : java)

1. interface RoomTtpeImage {
2.    public byte[][] getImage();
3.    public Dimension getSize();
4. }

ProxyRoomTypeImage.java (Language : java)

1. class ProxyRoomTypeImage implements RoomTypeImage {
2.    ActualRoomTypeImage realImage;
3.  
4.    public byte[][] getImage() {
5.       if (realImage == null) {
6.          realImage = new ActualRoomTypeImage();
7.       }
8.       return realImage.getImage;
9.    }
10.  
11.    public Dimension getSize() {
12.       if (realImage == null) {
13.          realImage = new ActualRoomTypeImage();
14.       }
15.       return realImage.getSize();
16.    }
17. }

ActualRoomTypeImage.java (Language : java)

1. class ActualRoomTypeImage implements RoomTypeImage {
2.    private byte[][] imageDate;
3.    
4.    public ActualRoomTypeImage() {
5.       // ...
6.    }
7.  
8.    public byte[][] getImage() {
9.       // ...
10.    }
11.  
12.    public Dimension getSize() {
13.       // ...
14.    }
15. }

Client.java (Language : java)

1. public class Client {
2.    public static void main(String[] args) {
3.       RoomTypeImage roomImage = // 실제 객체의 프락시 객체
4.       byte[][] image = roomImage.getImage();
5.       Dimension size = roomImage.getSize();
6.       // ...
7.    }
8. }

4. 자바 프로그래밍 언어에서의 예

• Java RMI에서 Proxy 패턴(Remote Proxy Pattern)이 사용됨.
• RMI를 이용해 어플리케이션을 작성하고자 할 때 실질적으로 수행되어져 할 비즈니스 로직을 가지고 있는 비즈니스 오브젝트를 생성.
• 또한, 리모트 인터페이스(Remote Interface)를 생성합니다. 이 인터페이스에는
  클라이언트가 원격으로 사용할 수 있는 모든 메소드들이 선언.
• ava RMI 컴파일러는 스텁(Stub)클래스를 생성합니다. 이 스텁은 리모트 인터페이스를
  구현. 스텁 오브젝트는 프락시 오브젝트의 역할을 수행하고 있고, 클라이언트의 요청을 네트워크를 통해 리모트 오브젝트에게 전달하는 네트워킹 코드가 정의되어 있음.
• 클라이언트는 스텁 오브젝트에 정의되어 있는 비즈니스 메소드를 호출.
• 스텁은 클라이언트의 요청을 리모트 오브젝트에게 전달.
• 리모트 오브젝트는 클라이언트가 요청한 비니지스 로직을 수행.
• 수행 결과를 네트워크를 통해 스텁 오브젝트에게 리턴.
• 스텁 오브젝트는 다시 클라이언트에게 전달.

5. 결과

• 장점
  프락시 패턴을 사용할 경우 클라이언트가 로컬 환경에서 로컬 오브젝트와 커뮤니케이션 하는 경우와 리모트 환경에서 리모트 오브젝트와 커뮤니케이션 하는 방법이 동일.
  프락시를 사용할 경우 시스템에서 필요로 하는 추가적인 기능을 확장하기가 용이.
  프락시는 클라언트의 접근을 제어 또는 제한할 수 잇음.
• 단점
  클라이언트의 요청이 직접 리모트 오브젝트가 아닌 프락시 오브젝트를 통해 전달되기 때문에 수행 속도가 떨어질 수 있음.
  분산환경에서 에러가 날 경우 로컬 환경에서 보다 에러를 해결하기가 더 어려워질 수 있음.
  

happyness Programming/J2EE Patterns Proxy, Structural, 구조패턴

종종 프로그램이 전개되고 개발됨에 따라, 프로그램들은 복잡해짐. 사실, 디자인 패턴을 이용하는 거에 대한 흥분은 이러한 패턴들이 때때로 프로그램의 흐름을 이해하는 것을 어렵게 하는 많은 클래스들을 생성한다는 것임. 게다가, 그것들은 복잡한 시스템일 수도 있고, 복잡한 인터페이스를 가지고 있을 수도 있음.
Facade 패턴은 이러한 하위 시스템에 대한 간단한 인터페이스를 제공하여 복잡한 것을 간단히 만드는 것. 이 간단성이 놓여있는 클래스의 유연성을 줄이는 경우가 있지만, 보통 대부분의 약아빠진 사용자들을 제외하고는 모두에게 필요한 함수를 제공.
다행스럽게도, 우리는 Facade가 유용하게 사용될 수 있는 예에 대하여 제공되는 복잡한 시스템을 작성할 필요가 없음. 자바는 JDBC라 불리는 인터페이스를 사용하여 데이터베이스에 연결되는 클래스들의 집합을 제공. 프로그램 개발자가 제공하는 JDBC 연결 클래스를 이용하여 어떤 데이터베이스 든  연결할 수 있음. 몇몇 데이터베이스드은 JDBC를 이용하여 직접적인 연결을 할 수 있고 몇몇은 JDBC-ODBC bridge 클래스를 이용하여 ODBC 드라이버에 연결을 허용.

1. 의도
서브 시스템에 있는 인터페이스 집합에 대하여 하나의 통합된 인터페이스를 제공. Facade 패턴은 서브 시스템을 좀 더 사용하기 편하게 하기 위해서 높은 수준의 인터페이스를 정의.

2. 고려해야 할 사항
많은 디자인 패턴들은 쉬운 유지보수와 높은 재사용성을 위해 클래스를 작고, 응집력이 높도록 만드는 경향이 있음. 따라서 많은 서스 시스템은 많은 수의 클래스를 가지게 됨. 이 클래스들을 클라이언트가 직접 사용할 경우, 클라이언트와 서스 시스템간 결합도가 높아지는 문제가 발생함. 그리고 클라이언트 클래스와 서브 시스템에 존재하는 클래스간 결합도가 높아질 경우 다음과 같은 문제을 발생시킬 수 있음.

• 서브 시스템 내에 존재하는 클래스를 수정할 경우, 클라이언트가 영향을 받음. 이럴 경우 시스템이 깨지기 쉽고(Brittleness가 높음), 적응성(Adaptability)이 낮게 됨.
• 클라이언트 클래스 작성 프로그래머는 클래스가 제공하는 모든 인터페이스에 대해 알아야 함. 이럴 경우 시스템 수정이 복잡해지고 시간이 오래 걸리게 됨.
• 클라이언트는 서브 시스템의 오퍼레이션 순서의 정확한 순서를 알아야 하고, 오퍼레이션간 상태를 전달해야 함. 이럴 경우 클라이언트가 서브 시스템의 관련 로직을 알고 있어야 함.
• 클라이언트와 서스 시스템은 서로 다른 머신에 위치하고 있을 경우, 많은 메소드 호출과 상태 전달은 네트워크 오버헤드를 증가시키는 원인이 됨.

3. 구조

ReservationServiceFacade.java (Language : java)

1. class ReservationServiceFacade {
2.    Reservation reservation;
3.    HotelSearchService service;
4.    Room room;
5.    Guest guest;
6.  
7.    public void cancelReservation() {
8.       reservation.cancel();
9.       // ...
10.    }
11.  
12.    public void confirmReservation() {
13.       reservation.confirm();
14.    }
15.  
16.    public boolean findRoom() {
17.       service.findRoom(...);
18.    }
19.  
20.    public void makeReservation(...) {
21.       Room[] rooms = rooms.service.findRooms();
22.       Room theRoom = // 조건에 맞는 룸
23.       guest = new Guest();
24.       reservation = new Reservation(theRoom, theGuest);
25.       theRoom.updateStatus(...);
26.    }
27.  
28.    public void modifyReservation(...) {
29.       reservation.modifyReservation(...);
30.    }
31. }

HotelSearchService.java (Language : java)

1. class HotelSearchService {
2.    public Collection findRoom(...) {
3.       // ...
4.       return rooms;
5.    }
6. }

Guest.java (Language : java)

1. class Guest {
2.    public void updateProfile(...) {
3.       // ...
4.    }
5. }

Room.java (Language : java)

1. class Room {
2.    public void updateStatus(...) {
3.       // ...
4.    }
5. }

Reservation.java (Language : java)

1. class Reservation {
2.    public void cancel(...) {
3.       // ...
4.    }
5.  
6.    public void create(...) {
7.       // ...
8.    }
9.  
10.    public void update(...) {
11.       // ...
12.    }
13. }

Client.java (Language : java)

1. public class Client {
2.    public static void main(String[] args) {
3.       // ...
4.       ReservationServiceFacade facade = new ReservationServiceFacade();
5.       facade.makeReservation(...);
6.       // ...
7.    }
8. }

4. 자바 프로그래밍 언어에서의 사용 예

• java.net.URL 클래스가 Facade의 역할을 수행. 이 클래스는 URL이 가지고 있는 내용들을 접근하기 위한 API를 제공.
• 하나의 클래스가 URL 클래스의 클라이언트가 되고, 클라이언트는 java.net.URL 클래스를 이용해 URL 클래스에 의해 제공되는 Facade 뒤쪽에서 얼마나 많은 클래스들에 의해 운영이 되고 있는지에 대한 정보가 없어도 URL 정보를 얻을 수 있음.
• 다른 한편, 데이터를 URL에 전송하기 위해 URL 오브젝트의 클라이언트는 openConnection 메소드를 호출. 이 메소드는 URL 오브젝트가 사용하는 URLConnection 오브젝트를 리턴.

5. 결과

• 장점
  서스 시스템 콤포넌트들은 클라이언트에게 은폐되어 있기 때문에, 클라이언트가 알아야 할 오브젝트 수가 줄어듬. 따라서, 클라이언트는 서스 시스템을 사용하기 더 쉬워짐.
  분산환경에서 네트워크 오버헤드가 감소.
  클라이언트와 서스 시스템간 결함이 느슨해짐. 따라서, 클라이언트에 영향을 주지 않으면서 서스 시스템을 변경시킬 수 있음.
  서브 시스템 클래스는 사용하는 것을 완전히 막지는 않음. 그러므로 Facade를 사용할지 서스 시스템 클래스를 직접 사용할지를 결정할 수 있음.
• 단점
  서스 시스템내에 존재하는 콤포넌트에 직접 억세스하는 것이 아니라, Facade를 통해서 접근하고 있기 때문에 수행속도에 영향을 줄 수 잇음.
  

happyness Programming/J2EE Patterns Facade, Structural, 구조패턴

1. 정의 및 특성

• 정의: 구조 패턴은 더 큰 구조를 형성하기 위해 어떻게 클래스와 객체를 합성하는가와  관련된 패턴
• 특성: 구조 패턴은 상속과 연관(Association) 관계를 이용해 클래스들을 서로 조립하고 있음.
  구조 클래스 패턴은 상속 기법을 이용하여 인터페이스나 구현을 합성.
  예를 들어, 다중 상속을 통해서 둘 이상의 클래들을 하나로 만들 수 있음. 이럴게 만들어진 클래스는 부모 클래스에 정의된 모든 특성들을 혼합하여 갖게 됨, 이 패턴은 서로 독립적으로 개발한 클래스 라이브러리를 하나인 것처럼 사용할 필요가 있는 경우라면 매우 유용한 방법.
  구조 객체패턴은 새로운 기능을 실현하기 위해 객체를 합성. 객체 합성이 갖는 유연성으로 인해 런타임 시 합성의 방법이나 대상을 변결할 수 있음.
  다른 GoF 패턴들 처럼, Adaptability, Reusability, Maintenability를 강조.

2. 종류

• Facade 패턴
  서브 시스템에 있는 인터페이스 집합에 대하여 하나의 통합된 인터페이스를 제공. Facade 패턴은 서브 시스템을 좀더 사용하기 편하게 하기 위해서 높은 수준의 인터페이스를 정의.
• Proxy 패턴
  다른 객체로의 접근을 통제하기 위해서 다른 객체의 대리자 또는 다른 객체로의 정보 보유자를 제공함.
• Adapter 패턴
  클래스의 인터페이스를 클라이언트가 기대하는 다른 인터페이스로 변환. Adapter 패턴은 호환성이 없는 인터페이스 때문에 함께 사용할 수 없는 클래스를 개조하여 함께 작동하도록 함.
• Composit 패턴
  부분-전체 계층을 나태내기 위해 복합 객체를 트리구조로 만듬, Composit 패턴은 클라이언트가 개별적 객체와 복합 객체 모두를 동일하게 다루도록 함.
• Decorator 패턴
  객체에 동적으로 책임을 추가할 수 있게 함. Decorator 패턴은 기능이 유연한 확장을 위해 상속 대신 사용할 수 있는 방법.
  

happyness Programming/J2EE Patterns Strucural, 구조패턴