'전체 글'에 해당되는 글 678건

  1. 2011.08.13 [펌] Creational Patterns
  2. 2011.08.13 [펌] Behavioral Patterns
  3. 2011.08.13 [펌] AbstractFactory
  4. 2011.08.13 [펌] 디자인패턴이란?

Creational Patterns

모든 Creational Patterns은 객체의 인스턴스를 생성하는 최상의 방법과 관련이 있다. 이것은 작성된 프로그램이 생성되고 배치된 객체들과 의존적이지 않아야 하기 때문에 중요하다. 자바에서는 가장 간단한 방법으로 new 연산자를 이용하여 객체들의 인스턴스를 생성하는 방법이다. 

                                Fred = new Fred() ; //instance of Fred class

그러나 이 방법은 프로그램 안에서 생성된 객체가 의존적이어서 결국 코딩이 어렵게 된다. 많은 경우에, 생성된 객체의 정확한 본질은 프로그램의 요구에 의하여 변경되어 질 수 있고, "createor"라는 특수한 클래스로의 추상화 과정은  프로그램을 보다 유연하고 일반적으로 만들 수 있게 한다.

The Factory Method ##########0*

Factory 패턴은 제공되는 데이터에 의존하는 추상 기저 클래스의 가능한 하위 클래스들 중의 하나를 반환하는 간단한 의사 결정 클래스를 제공한다.

The Abstract Factory Method ##########1*

Abstract Factory 패턴은 생성할 인터페이스를 제공하고, 관련된 객체들의 여러 군 중에서 하나를 반환한다.

The Singleton Pattern ##########2*

Singleton 패턴은 오직 하나의 인스턴스만을 갖는 클래스이다. 그 것은 생성된 인스턴스에 접근하는 하나의 포괄적인 점을 제공한다.

The Builder Pattern ##########3*

Builder 패턴은 단지 객체에 대한 형태와 내용만 지정함으로써, 복잡한 객체를 구성 할 수 있다. 즉, 각각의 객체 구성에 대한 모든 정보를 자세히 알고 있지 않아도 쉽게 객체를 구성 할 수 있다. 

The Prototype Pattern ##########4*

Prototype 패턴은 어떤 객체의 생성 방식에 대한 자세한 정보를 모르더라도 그 객체가 원하는 다른 객체를 생성할 수 있도록 도와준다. 우선, 생성하려는 객체에 대한 프로토타입 객체를 미리 제공한 다음, 프로타입 객체의 복사본을 생성함으로써

'Development > 패턴자료' 카테고리의 다른 글

[펌] Structural Patterns  (0) 2011.08.13
[펌] Some Background on Design Patterns  (0) 2011.08.13
[펌] Behavioral Patterns  (0) 2011.08.13
[펌] AbstractFactory  (0) 2011.08.13
[펌] 디자인패턴이란?  (0) 2011.08.13
안정적인 DNS서비스 DNSEver DNS server, DNS service
Posted by 키르히아이스
,

Behavioral Patterns

    Behavioral 패턴들은 객체들 사이의 통신과 관련된 가장 명확한 패턴이다. 이 단원에서는 다음과 같은 패턴들을 살펴볼 것이다.

The Observer Pattern ##########0*

Observer 패턴은 클래스들이 서로 변경을 알아 챌 수 있도록 하는 방법을 정의한다.

The Mediator Pattern ##########1*

Mediator 패턴은 클래스간에 서로 아는 것을 갖는 것으로부터 모든 클래스들을 유지하기 위하여  또 다른 클래스를 사용함으로써 간단하게 클래스 간의 통신을 어떻게 할 지를 정의한다.

The Chain of Responsibilty Pattern ##########2*

Chain of Responsibility 는 클래스가 인식될 때까지 클래스들 사이의 요청을 전달하여 클래스들 사이의 디커플링을 훨씬 더 허용하는 것이다. 

The Template Pattern ##########3*

Template 는 알고리즘의 추상적인 정의를 제공한다.

The Interpreter Pattern ##########4*

Interpreters 는 프로그램에서 언어 요소들을 어떻게 포함할 것인가에 대한 정의를 제공한다. 

The Strategy Pattern ##########5*

Strategy 는 하나의 클래스 내부에서 알고리즘을 캡슐화한다.  

The Visitor Pattern ##########6*

Visitor 패턴은 클래스에 함수를 추가한다.

The State Pattern ##########7*

State 패턴은 클래스의 인스턴스 변수들을 위한 메모리를 제공한다.

The Command Pattern ##########8*

Command 패턴은 명령의 실행을 일으키는 인터페이스 환경으로부터 명령의 실행을 분리하기 위한 간단한 방법을 제공한다.

The Iterator Pattern ##########9*

Iterator 패턴은 클래스에 있는 데이터의 목록을 통하여 우리는 이동하는 방법을 공식화한다.

'Development > 패턴자료' 카테고리의 다른 글

[펌] Some Background on Design Patterns  (0) 2011.08.13
[펌] Creational Patterns  (0) 2011.08.13
[펌] AbstractFactory  (0) 2011.08.13
[펌] 디자인패턴이란?  (0) 2011.08.13
싱글턴 패턴의 남용으로 발생하는 문제  (0) 2011.08.13
안정적인 DNS서비스 DNSEver DNS server, DNS service
Posted by 키르히아이스
,

앞서봤던 FactoryMethod는 하나의 객체를 어떻게 어디서 생성할 것인가에 초점을 뒀다.

AbstractFactorty는 내부적으로 FactoryMethod를 사용하면서 하나의 객체가 아니라,

객체의 군을 생성하는데 초점을 둔다.

즉, FactoryMethod에 하나의 Factory를 덧씌운 패턴이다.

제품군의 예를 들면 스킨이다.

버튼의 예를 들면, 결국 만드는 것은 버튼이지만 스킨에 따라서 모양이 틀리고 이미지가 틀리다.

버튼이 하나의 제품군을 이루는 것이다.

 

조건문을 사용해서 그때마다 맞는 객체를 생성하게 되면 곳곳에 비교 문장이 산재하게 되므로 객체 생성 부분이 흩어여 존재하게 된다.(FactoryMethod와 동일)

이것은 새로운 조건을 추가할 경우 이전 코드와 무관하게 작업할 수 없다는 것이 문제이다.

물론 프로그램 시작 부분에서 객체를 한 번에 생성하고 참조만으로 사용할 수도 있다.

그러나 이것은 미리 객체를 생성해야 한다는 부담이 있고, 한꺼번에 원시 코드를 여러개 컴파일해야 한다는 부담도 있다.

AbstractFactory를 사용해도 물론 수정은 피할 수 없다. 하지만 이 수정이라는 것은 이전 코드와는 독립된 확장이다. AbstractFactory에서는 이러한 가능성을 배제할 수 있게 해 준다.

 

객체 지향 설계의 가장 기본적인 철칙은 변경이 예상되는 부분을 국지화 시킨다는 것을 잊어선 안된다.

 

유용한 경우

1. 객체 생성을 클라이언트가 직접 하지 않고, 간접적으로 수행함으로써, 클라이언트가 객체의 생성 이나 구성에 독립적이도록 만들 때.

2. 여러 제품군 중 사용할 제품군을 쉽게 선택 하도록 만들 때.

 

정리.

1. 객체가 생성되는 방식이나 과정 및 책임을 클라이언트가 모르게 한다. 이때 클라이언트는 AbstractFactory, AbstractProduct의 인터페이스만 알 뿐이다.

2. 제품군의 교체가 쉽다.

->ConcreteFactory 클래스의 객체가 생성되는 부분만 변경하면 된다.

3. 여러 제품군이 섞이는 것을 방지할 수 있다.

->ConcreteFactory 클래스는 특정 제품군만을 생성한다.

4. 제품군이 늘어날 수록 모든 Factory클래스의 수정이 불가피하다.

->ErrorHandler 같은 새로운 제품군이 필요하면 모든 Factory 클래스에 CreateErrorHandler() 메소드를 추가시켜줘야 한다.

'Development > 패턴자료' 카테고리의 다른 글

[펌] Some Background on Design Patterns  (0) 2011.08.13
[펌] Creational Patterns  (0) 2011.08.13
[펌] Behavioral Patterns  (0) 2011.08.13
[펌] 디자인패턴이란?  (0) 2011.08.13
싱글턴 패턴의 남용으로 발생하는 문제  (0) 2011.08.13
안정적인 DNS서비스 DNSEver DNS server, DNS service
Posted by 키르히아이스
,
##########0*

강사 : 조남일

- 디자인스톰 웹자동화 시스템 개발
- 프루덴셜 생명 포탈 시스템 개발
- 한국통신 공중전화 시설관리 시스템 개발
- (현)삼성전자 GSCM SYSTEM 유지보수
- 숭실대 정보과학대학원 소프트웨어공학과 재학중

 

강좌개요
 
 Software Design Patterns에 관련한 책 중에
 GoF(Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides also known as the Gang of Four)의  Design Patterns(Elements of Reusable Object-Oriented Software)라는 책이 1995년에 나온 후부터 수 많은 디자인패턴 관련 서적들이 나왔고 GoF의 디자인 패턴은 관련 서적중 Bible의 역할을 해왔습니다.
 다만 이 책이 C++과 Smalltalk를 이용해서 디자인 패턴을 설명했으므로 자바 개발자인 저로서는 약간의  Java로 되어있었으면 하는 아쉬움이 있었습니다.

 부족하나마 제가 Design Pattern 관련 강의를 하게 되었습니다.
 
 이 강좌에서는 GoF의Desgign Patterns에 명기된 순서대로 23가지 Design Pattern을 다룰 것이고
 GoF의 C++버전을 Java로 표현하도록 하겠습니다.
 
 
대상 : Java언어가 뭔지 아는 Java 초보자 및 Design Pattern이 뭔가하는 Java 개발자
       ※ 추가로 UML의 Class Daigram정도는 보고 이해할 수 있어야 한다. 만약 아직
          UML을 접해보지 않으신 분들은 먼저 UML관련 서적 중 Class Daigram관련 부분만이라도
   미리 공부해 두길 바랍니다.
목표 : GOF의 23개 디자인 패턴을 이해함으로써 프로그래머로써의 Skill Upgrade

 

강좌 계획서

0. 강좌 개요
1. 디자인 패턴이란?
2. 생성 패턴(Creational Patterns)
2.1 Abstract Factory
2.2 Builder
2.3 Factory Method
2.4 Prototype
2.5 Singleton
3. 구조패턴(Structural Patterns)
3.1 Adapter
3.2 Bridge
3.3 Composite
3.4 Decorator
3.5 Facade
3.6 Flyweight
3.7 Proxy
4. 행위패턴(Behavioral Patterns)
4.1 Chain of Responsibility
4.2 Command
4.3 Interpreter
4.4 Iterator
4.5 Mediator
4.6 Memento
4.7 Observer
4.8 State
4.9 Strategy
4.10 Template Method
4.11 Visitor

 

강좌는 강좌개요의 각 단원별로 올리겠습니다.

 

먼저 기본적인 용어정의, History,간단한 소개등으로 문을 열겠습니다.

 

1.1 용어의 정의

1.1.1 사전적 의미의 pattern

- a. A model or an original used as an archetype. : 원형(prototype)

   b. A person or thing considered worthy of imitation. : 모범,전형

- A plan, diagram, or model to be followed in making things: 방향,경향;(type),형태

- A representative sample; 견본

 

1.2 소프트웨어 개발에서의 pattern(Design Pattern)

1.2.1. 포괄적 의미

-특정 환경(프로젝트)에서 반복적으로 발생하는 설계문제들에 대한 일반적인 해결책이다.

-이미 많은 검증을 거첬기 때문에 특정 문제에 대한 좋은 해답이라는 것이 분명하므로

 다른 프로젝트에도 적용이 가능하겠죠!!(재사용성)

-설계문제, 제안된 해결책, 그리고 설계문제 또는 해결책에 영향을 미칠 다른 요인들(factors)에 대한

 정형화된 접근방법(formal approach)을 사용한다.

 한마디로 어떤 문제점,해결책 등에 대해 명확한 Rule이 정의되어 있어 이를 사용한다는 의미입니다.

-위 세가지를 모두 만족해야 좋은 Pattern이라 할 수 있겠죠?

 

1.2.2. 객체지향 프로그램에서의 Design Pattern

-GoF의 저자 서문에서 명기한 대로 "객체지향 소프트웨어를 설계시 특정 문제에 대한 간결하고 명확한 솔루션"이다.

 즉 어떤 상황을 해결하기 위한 잘 알려지고 검증된 해답이다.

 

위의 말들을 다시 정리하면

S/W에서의 Desing(설계) 패턴이란

-S/W설계시 특정 문제(또는 환경)가 반복적으로 발생하고

-이를 해결하기 위한 해결책이 일반적으로 잘 알려져 있으며

-간결하고 명확하고 검증된 것일 때

이를 패턴이라 할 수 있다.

 

1.3 디자인 패턴의 History

-1977년 건축가인 크리스토퍼 알렉산더(Christopher Alexander)의 저서인 "A Pattern Language:Towns, Buildings, Construction"에서

 건축물의 설계에 자주 발생하는 동일 설계 내용이 있으며

 이런 것들을 하나의 패턴으로 보고

 다른 건축물 설계에 재사용함으로써 많은 이점을 얻을 수 있다고 언급하였다.

 , 반복적으로 발생하는 문제를 풀기위해 공통적인 Pattern을 사용한다는 개념이 언급되었다.

 

-1987 Ward Cunningham Kent Beck OOPSLA-87에 발표한 논문

 "Using Pattern Languages for Object-Oriented Programs"에서 사용자 인터페이스(User interface)에 대한 다섯 가지의 패턴 소개.

 소프트웨어분야에서 디자인 패턴에 대해서 학계에 공식적으로 알리는 계기가 되었다.

 

  OOPSLA-87(Object-Oriented Programming, Systems, Languages & Applications : 87)

 

- 1990년대 초기 이후 S/W개발자들 사이에서 빠르게 알려지기 시작함.

- 1994 GOF Design Patterns: Elements of Reusable Object-Oriented Software 이후 확산됨.

  GOF(the Gang of Four : E. Gamma, R. Helm, R. Johnson, and J. Vlissides)

 .OOP(object-oriented design)에서의 전형적인 문제에 대한 해결책을 제시하는 23가지 기본 패턴을 포함하고 있으며

 .디자인 패턴에 대한 아이디어를 널리 알리는 계기를 만들었다.

 

Design Pattern을 사용함으로써 얻어지는 이점

그럼 디자인 패턴을 사용함으로써 얻어지는 이점은 어떤 것들이 있을까요?

1. 디자인 패턴을 적용하여 그대로 해결할 수 있는 문제라면 말할 필요도 없이

시간절약, 머리쓰는 에너지 절약이죠.

2. 개발자로서 좋은 해결책들을 Study함으로써 사고의 폭도 넓어지겠죠.

3. 좋은 의사소통의 수단이 될 것입니다.

디자인 패턴은 객체나 컴포넌트의 모델링단계에서 개발자들간에

빠른 시간 내에 정확한 의사 전달을 하기 위한 수단으로 활용할 수 있을 것입니다.

예를 들어 개발자들이 디자인 패턴을 잘 알고 있는 경우라면

기본적인 MVC모델기반으로 개발하는 경우

"Servlet에서 Business Logic이 들어있는 Beans에 접근하는 방법은 Facade Pattern을 사용하죠.."라고

설명하면 되지만,

그렇지 않을 경우

어떻게 인스턴스를 생성하고...

어떻게 인스턴스가 return되고 등을 말로 설명하기는 매우 힘들 것이고

아마 직접 source code를 보아야만 서로 이해가 될 것입니다.

 

1.4 Design Pattern의 분류

1.4 .1 Design Pattern의 목적에 따른 세가지 분류

1.4.1.1 생성패턴(Creational Pattern)

-Programmer가 직접 객체를 생성하지 않고 Pattern을 이용하여 생성

-주어진 상황에 따라 객체를 유연하게 생성할 수 있음

-객체의 생성 방식을 결정하는데 포괄적인 솔루션을 제공하는 패턴

(클래스의 인스턴스화 절차를 추상화 함)

-클래스 정의와 객체 생성방식을 구조화,캡슐화하는 방법을 제시

 

1.4.1.2. Structural Pattern

-Class와 객체가 더 큰 구조로 조합되는 방법을 정의

 

1.4.1.3. Behavioral Pattern

-System상의 객체들의 통신과 그 흐름이 복잡한 Program상에서 Control되는 방법을 정의

 

1.4.2 적용범위에 따른 분류

나중에 학습을 계속해보면 알겠지만

세가지 Creational, Structural, Behavioral Pattern들은 Pattern

클래스와 서브클래스사이의 관계를 다루는지

아니면 객체간의 관계를 다루는지에 따라서 아래의 두가지 분류로 나눌 수 있다.

 

1.4.2.1. Class Pattern

- Class SubClass사이의 관계를 다룸

- Static (Compile time에 고정됨)

 

1.4.2.2. 객체 Pattern

- 객체간의 관계를 다룸

- Dynamic Binding( Runtime )

 

23가지 디자인 패턴의 목적과 범위에 따른 분류

 

목적

생성(Creational)

구조(Structural)

행위(Behavioral)

범위

클래스

Factory Method

Adapter

Interpreter

Template Method

객체

Abstract Factory

Builder

Prototype

Singleton

Adapter

Bridge

Composite

Decorator

Facede

Proxy

Chain of Responsibility

Command

Iterator

Mediator

Memento

Flyweight

Observer

State

Strategy

Visitor

 

위에서 보면 Structural Pattern Adapter Pattern의 경우 범위에 따른 분류시 클래스, 객체 모두에

포함됨을 알 수 있습니다. 한마디로 Adapter Pattern을 적용하는 방법이 두가지라는 말도 됩니다.

 

1.5 Design Pattern Catalog

아래는 앞으로 배울 23가지 디자인 패턴에 대한 간단한 설명입니다.

참고로 여기에서 쓰이는 인터페이스,Operation은 자바에서 쓰이는 method를 의미합니다^^

--생성 패턴(Creational Patterns)

1.5.1 Abstract Factory

구체적인 클래스를 지정하지 않고 서로 관련있는 또는 서로 독립적인 객체들의 집합을 생성한다.

1.5.2 Builder

  객체의 생성 로직을 인스턴스화할 Class의 외부에 둔다.

1.5.3 Factory Method

  서브클래스에게 인스턴스 생성의 책임을 미룬다.

  즉 객체를 생성하는 인터페이스를 정의한다.

  그러나 어떤 클래스이 인스턴스를 생성할지에 대한 결정은 서브클래스가 한다.

1.5.4 Prototype

  원형(Prototype) 인스턴스를 만들고 이것을 복사해서 새로운 객체들를 만든다.

1.5.5 Singleton

  클래스가 오직 하나의 인스턴스를 가지도록 한다. 모든 접근은 이 하나를 통해서만 가능하다.

--구조패턴(Structural Patterns)

1.5.6 Adapter

  서로 다른 인터페이스를 갖는 클래스들을 같이 동작할 수 있도록 한다.

1.5.7 Bridge

  추상화개념과 구현을 분리시킨다.

1.5.8 Composite

  부분과 전체의 계층을 표현하기 위해 복합 객체를 트리구조로 만든다.

1.5.9 Decorator

  객체에 동적으로 새로운 서비스를 추가한다.

1.5.10 Façade

  서브시스템을 사용하기 쉽도록 인터페이스를 제공한다.

1.5.11 Flyweight

  공유 개념을 도입하여 많은 객체들을 효율적으로 사용하게 한다.

1.5.12 Proxy

  특정 객체에 대한 접근을 대리하는 역할을 하는 객체를 둔다.

--행위패턴(Behavioral Patterns)

1.5.13 Chain of Responsibility

  하나의 객체에게 보낸 메시지가 다른 객체에게 자동으로 전달된다.

  요청자와 처리자가 확정되지 않는다.

1.5.14 Command

  요청 자체를 객체로 만들이서 이 객체를 파라미터화 하거나, 명령리스트에 저장하는 등의 방식으로 사용할 수 있게 한다.

1.5.15 Interpreter

  어떤 문장에 대한 표현을 제공하고 그 문장을 해석하는 방법을 제공한다.

1.5.16 Iterator

  Collection에 담긴 요소에 대해 순차적 접근방법을 제공한다.

1.5.17 Mediator

  객체들사이에 중재자로서 새로운 객체를 둔다.

  객체들간의 종속성을 줄인다.

1.5.18 Memento

  객체의 상태를 저장하여 객체를 저장해둔 상태로 다시 복구할 수 있게 한다.

1.5.19 Observer

  객체들간의 종속성을 관리한다.

  특정 객체에 종속된 모든 객체들을 한 객체의 상태가 변경되면 이를 자동으로 통지 받는다.

1.5.20 State

  객체가 자신의 내부상태에 따라 다른 행위를 하게 한다.

1.5.21 Strategy

  다양한 알고리즘이 존재할 때 이들을 각각의 클래스로 만들어 알고리즘의 대체가 가능하도록 한다.

1.5.22 Template Method

  오퍼레이션에서 알고리즘의 기본 골격구조를 정의하고 구체적인 구현은 서브클래스에서 한다.

1.5.23 Visitor

  객체 구조에 속한 요소에 수행될 오퍼레이션을 정의한다.

 

<출처 : 네트워커의 블로그입니다>

'Development > 패턴자료' 카테고리의 다른 글

[펌] Some Background on Design Patterns  (0) 2011.08.13
[펌] Creational Patterns  (0) 2011.08.13
[펌] Behavioral Patterns  (0) 2011.08.13
[펌] AbstractFactory  (0) 2011.08.13
싱글턴 패턴의 남용으로 발생하는 문제  (0) 2011.08.13
안정적인 DNS서비스 DNSEver DNS server, DNS service
Posted by 키르히아이스
,