A-1

A. 설계 패턴 (Design Pattern) 소개

A-2

설계 패턴이란 ?• 설계패턴은 특정 문맥에서 일반적인 설계문제를 해결하도록

맞추어진 , 상호 협력하는 객체들과 클래스 들에 대한 기술

• Design patterns are descriptions of communicating objects and classes that are customized to solve a general design problem in a particular context– Gamma E., et al.

Design Patterns: Elements of Reusable Object-Oriented Software. Addison Wesley, 1995.

A-3

설계 패턴이란 ?• 설계패턴은 자주 발생하는 설계상의 문제를 해결하기 위한 반복적인

해법 [Smalltalk Companion]

• 설계패턴은 반복되는 구조를 설계할 때 설계를 재 활용하는데 초점을 두는데 비하여 프레임워크는 세부 설계와 구현에 초점을 두고 있다 .[Coplien & Schmidt]

A-4

History• 1960~70 년대 건축설계분야에서 pattern 개념 사용

(Christopher Alexander)• 1987: ward & kent came up with a five patterns that helped the novi

ce designers. [OOPSLA 87]• 1991: Erich Gamma & Richard Helm put together the very humble be

ginnings of the catalog of patterns.• 1995: The first PLoP(Pattern Languages Of Program design) proceedi

ngs come out.• 1995: The book “Design Patterns: Elements of Reusable Object-Orie

nted Software” * is published• 현재 Patterns 은 S/W 의 각 분야에서 이용됨

– Analysis Pattern, Process Pattern, …

A-5

설계 패턴의 예 : MVC 패턴• Design Patterns in Smalltalk MVC

– MVC (Model-View-Controller) Pattern

• Smalltalk 에서 User Interface 를 만들기 위한 패턴• 3 가지 종류의 객체로 구성

• Model (data): 화면에 출력될 자료 관리• View: 화면 출력 담당• Controller: 사용자와 view 간의 상호작용을 담당

• MVC 는 view 와 model 을 분리하고 이들 간의 “ subscribe/ notify” 프로토콜을 이용하여 동작

A-6

설계 패턴의 예 : MVC 패턴

Model

Views

Controller

Model

Views

Controller

A-7

The Catalog of Design Patterns• 다양한 수준의 설계패턴 존재

– 프로그래밍 수준 --- 추상화된 상위계층 수준

• 수 천 가지 이상의 패턴들이 발표되었으며 , 문서와 국제회의에서 토의되고 있음

• 일반 개발자는 새로운 설계패턴을 작성하기 보다는 이미 정리되어 있는 설계패턴을 활용하는 것이 바람직함

• GoF 에서 23 개의 설계패턴을 3 가지 유형으로 분류하여 목록 (Catalog) 화 해 놓음

A-8

설계 패턴의 3 가지 유형• Creational Pattern

– 객체를 생성하는데 관련된 패턴들– 객체가 생성되는 과정에 유연성을 높이고 , 코드의 유지가

쉬워진다 .

• Structural Pattern– 프로그램의 구조에 관련된 패턴들– 프로그램내의 자료구조나 인터페이스 구조 등 프로그램의

구조를 설계하는데 많이 활용될 수 있는 패턴들

• Behavioral Pattern– 반복적으로 사용되는 객체들의 상호작용을 패턴화 해 놓은 것

A-9

GoF Pattern Catalog• Creational Patterns

– Abstract Factory– Prototype– Singleton– Factory Method– Builder

• Structural Patterns– Adapter– Bridge– Composite– Decorator– Flyweight– Façade– Proxy

• Behavioral Patterns– Chain of Responsibility– Command– Interpreter– Iterator– Mediator– Memento– Observer– State– Strategy– Template Method– Visitor

A-10

지속적인 설계 변경• 여러가지 이유 때문에 설계는 지속적으로 변경된다

– 불충분한 요구사항 정의– 기능의 추가– 설계의 결함– 기술 환경의 변화

• 설계 변경 요청에 대한 유연한 대처– 설계 변경이 쉽다

• 설계 변경 비용– 이곳 저곳 많이 고쳐야 하나 ?– 기존의 설계 / 코드는 거의 고치지 않고 ,

한 곳에서 설계 / 코드 수정 / 추가로 해결 ?

A-11

설계 패턴의 목적• 설계 변경 요청에 대한 유연한 대처를 가능케 한다

– 이곳 저곳 많이 고칠 필요 없다

• 바람직한 모듈 ( 객체 ) 구조가 만들어짐– 역할별 모듈 ( 객체 ) 분리

• 역할별 분리로 인한 재사용성 향상

A-12

설계 패턴의 단점• 객체지향 설계이어야 한다

– C 를 이용한 구조적 설계에 별 도움이 안됨

• 객체지향 언어로 구현해야 한다– C 로 구현할 수 있기는 하지만 , 너무 복잡해진다

• 초기 투자 비용이 더 든다– 설계 패턴을 적용하여 설계 구현할 때

초기에 시간과 노력이 더 든다– 하지만 이후 설계 변경 비용은 감소한다– 설계 변경이 많다면 결과적으로 이익– 설계 변경이 별로 없다면 ?

A-13

설계 변경 유형• 각 설계 패턴은

– 특정 유형의 설계 변경에 대해 – 유연한 대체를 가능케 한다

• 설계 패턴을 잘 활용할 수 있으려면– 어떤 유형의 설계 변경에 대한 설계 패턴인지 아는 것이 중요

A-14

설계 패턴의 이해• 어떤 유형의 설계 변경에 유연한 대처가 가능한가 ?

• 이 설계 패턴을 적용하지 않았을 때 발생하는 문제점은 ?

• 이 설계 패턴을 적용하지 않고– 좀 더 단순하고 쉽게– 유연한 대처가 가능하도록 만들 수는 없는가 ?

A-15

Causes of redesign• Creating an object by specifying a class explicitly

– 객체를 생성할 때 특정 클래스의 이름을 코드 상에서 구체적으로 지정한다면 향후 코드 변경에 어려움이 생긴다 .

• Dependence on specific operations– 특정 연산에 대한 요청을 하드코딩 (hard-coding) 한다면 ,

연산의 유연성이 떨어진다 .

A-16

Causes of redesign• Dependence on hardware and software platform

– 특정 플랫폼에 의존적인 Software 는 다른 플랫폼으로 이전하기 힘들다 .

– Software 의 플랫폼 의존성을 줄이는 것이 바람직하다 .

• Dependence on object representations or implementations– 만일 client code 가 특정 object 의 표현방식과 저장방식 ,

그리고 위치 등을 알아야 된다면 , 해당 object 에 변경이 이루어 질 때마다 client code 부분도 변경이 이루어져야 한다 .

– Client code 부분으로 부터 서비스하는 object 의 내부 정보를 숨기는 것이 바람직하다 . (low coupling)

A-17

Causes of redesign• Algorithmic dependencies

– S/W 시스템에 사용되는 algorithm 은 자주 확장 , 최적화 , 대체를 통하여 변경된다 . 변경되는 algorithm 에 의존적인 object 들 역시 변경될 가능성이 높다 .

– 자주 변경되는 algorithm 의 경우엔 다른 object 들과 분리시키는 것이 바람직

• Tight coupling– 서로 강하게 연결된 class 들의 경우 , 특정 class 하나가

변경되면 다른 class 들도 상당부분 변경되어야 한다 . – 서로 강하게 연결된 class 들은 이해하기 어렵고 , 재사용하거나

유지하기 힘들다 .– Coupling 은 가능한 한 낮추는 것이 바람직

A-18

Causes of redesign• Extending functionality by subclassing

– ( 구현 ) 상속을 통한 기능확장의 경우 상속관계가 깊어지면 이해하기 힘들다 .

– Class 수가 많아져서 관리하기 어렵다 .– ( 구현 ) 상속보다는 delegation 을 사용하는 것이 시스템을

유연하게 만드는 경우가 많다 .

A-19

Causes of redesign• Inability to alter classes conveniently

– 기존 시스템에서 작성된 class 의 기능 일부를 수정하려면 일반적으로 소스코드가 필요 . 상업적인 library 를 도입하여 기존 소스코드를 구할 수 없거나 변경할 수 없다면 ?

– 기존 class 의 소스코드를 변경하지 않더라도 , 해당 class 가 맡은 역할의 동작을 수정할 수 있게 구조화 할 수 있다 .

A-20

객체지향 설계 철학• 역할별 분리

– 객체화 , 모듈화

• 표준화– 인터페이스 표준화– 다형성

• 계층화– 계층화 아키텍처

A-21

객체지향 설계 철학• 역할별 분리

– 전체 로직을 한 덩어리로 만들지 않는다– 로직을 역할별로 객체로 분리한다– 각 객체는 단순 명료하게 요약될 수 있는 역할이 있어야 한다– 그 객체의 메소드는 요약된 역할에 포함되는 일만 수행해야 한다– 필요한 객체들을 선택하여 조립하여 전체 로직을 구현한다

• 표준화– 객체들을 조립할 수 있으려면 – 객체들이 만나는 부분 ( 인터페이스 ) 의 표준이 필요하다– 조립식 객체들은 이 표준을 준수해서 만들어져야 한다

A-22

객체지향 설계 철학• 계층화

– 큰 어플리케이션의 로직은 3 계층으로 나뉘는 것이 바람직– 주요로직 계층 , 단위 작업 계층 , 유틸러티 계층

• 주요로직 계층– 어플리케이션의 전체 로직의 흐름을 구현한다– 단위 작업 계층의 메소드들을 호출하여 전체 로직을 구현한다– 세부 로직을 구현하면 안된다– 자료구조에 직접 접근하면 안된다

• 단위 작업 계층– 어플리케이션의 세부 로직을 구현한다– 자료구조에 직접 접근한다

A-23

객체지향 설계 철학• 유틸러티 계층

– 어플리케이션과 무관한 유용한 공통 기능을 구현한다– 예 : linked list 와 같은 자료구조 클래스

string 클래스 , date time 클래스

A-24

재사용 단계• 1 단계 : 유틸러티 계층의 재사용 클래스들을 확보

– 가장 손쉬운 재사용– 상용 클래스 라이브러리들이 많다– 적절한 클래스 라이브러리를 선택하여 구입하고

개발자들을 교육 훈련하면 됨

• 2 단계 : 단위 작업 계층의 재사용 클래스들을 확보– 저절로 확보 되지 않음– 바람직한 설계가 중요– 재사용을 위한 설계가 필요– 중요한 설계 철학 : 역할별 분리 , 계층화

A-25

재사용 단계• 3 단계 : 주요로직 계층의 재사용 클래스들을 확보

– 가장 높은 단계의 재사용– 설계 패턴에 대한 깊이 있는 공부가 필요– 중요한 설계 철학 : 역할별 분리 , 계층화 , 표준화

• 어플리케이션 프레임웍 (Application Framework)– 1 단계 유틸러티 계층과– 3 단계 주요로직 계층 ( 어플리케이션의 골격 ) 의– 재사용 클래스들이 갖춰짐

A-26

설계 패턴들에서 살펴볼 점• 설계 변경에 어떻게 유연하게 대처하는가

– 이 설계 패턴은 어떤 종류의 설계 변경에 대한 대처인가

• 객체지향 설계 철학이 어떻게 반영되었는가– 설계 철학을 반영하여 어떤 장점이 생겼는가

• 이 패턴을 사용하지 않고도 설계 변경 문제를 해결할 수는 없나 ?– 설계 변경에 대한 융통성을 약간 희생하는 대신 더 단순하게 설계할 수는 없는지 생각해 본다 .