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

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

설계 패턴이란? • 설계패턴은 특정 문맥에서 일반적인 설계문제를 해결하도록 맞추어진, 상호 협력하는 객체들과 클래스 들에 대한 기술 • 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.

설계 패턴이란? • 설계패턴은 자주 발생하는 설계상의 문제를 해결하기 위한 반복적인 해법 [Smalltalk Companion] • 설계패턴은 반복되는 구조를 설계할 때 설계를 재 활용하는데 초점을 두는데 비하여 프레임워크는 세부 설계와 구현에 초점을 두고 있다.[Coplien & Schmidt]

History • 1960~70년대 건축설계분야에서 pattern개념 사용(Christopher Alexander) • 1987: ward & kent came up with a five patterns that helped the novice designers. [OOPSLA 87] • 1991: Erich Gamma & Richard Helm put together the very humble beginnings of the catalog of patterns. • 1995: The first PLoP(Pattern Languages Of Program design) proceedings come out. • 1995: The book “Design Patterns: Elements of Reusable Object-Oriented Software” * is published • 현재 Patterns은 S/W의 각 분야에서 이용됨 • Analysis Pattern, Process Pattern, …

설계 패턴의 예 : 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”프로토콜을 이용하여 동작

설계 패턴의 예 : MVC 패턴

The Catalog of Design Patterns • 다양한 수준의 설계패턴 존재 • 프로그래밍 수준 ---추상화된 상위계층 수준 • 수 천 가지 이상의 패턴들이 발표되었으며, 문서와 국제회의에서 토의되고 있음 • 일반 개발자는 새로운 설계패턴을 작성하기 보다는 이미 정리되어 있는 설계패턴을 활용하는 것이 바람직함 • GoF에서 23개의 설계패턴을 3가지 유형으로 분류하여 목록(Catalog)화 해 놓음

설계 패턴의 3가지 유형 • Creational Pattern • 객체를 생성하는데 관련된 패턴들 • 객체가 생성되는 과정에 유연성을 높이고, 코드의 유지가 쉬워진다. • Structural Pattern • 프로그램의 구조에 관련된 패턴들 • 프로그램내의 자료구조나 인터페이스 구조 등 프로그램의 구조를 설계하는데 많이 활용될 수 있는 패턴들 • Behavioral Pattern • 반복적으로 사용되는 객체들의 상호작용을 패턴화 해 놓은 것

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

지속적인 설계 변경 • 여러가지 이유 때문에 설계는 지속적으로 변경된다 • 불충분한 요구사항 정의 • 기능의 추가 • 설계의 결함 • 기술 환경의 변화 • 설계 변경 요청에 대한 유연한 대처 • 설계 변경이 쉽다 • 설계 변경 비용 • 이곳 저곳 많이 고쳐야 하나? • 기존의 설계/코드는 거의 고치지 않고, 한 곳에서 설계/코드 수정/추가로 해결?

설계 패턴의 목적 • 설계 변경 요청에 대한 유연한 대처를 가능케 한다 • 이곳 저곳 많이 고칠 필요 없다 • 바람직한 모듈(객체) 구조가 만들어짐 • 역할별 모듈(객체) 분리 • 역할별 분리로 인한 재사용성 향상

설계 패턴의 단점 • 객체지향 설계이어야 한다 • C를 이용한 구조적 설계에 별 도움이 안됨 • 객체지향 언어로 구현해야 한다 • C로 구현할 수 있기는 하지만, 너무 복잡해진다 • 초기 투자 비용이 더 든다 • 설계 패턴을 적용하여 설계 구현할 때 초기에 시간과 노력이 더 든다 • 하지만 이후 설계 변경 비용은 감소한다 • 설계 변경이 많다면 결과적으로 이익 • 설계 변경이 별로 없다면?

설계 변경 유형 • 각 설계 패턴은 • 특정 유형의 설계 변경에 대해 • 유연한 대체를 가능케 한다 • 설계 패턴을 잘 활용할 수 있으려면 • 어떤 유형의 설계 변경에 대한 설계 패턴인지 아는 것이 중요

설계 패턴의 이해 • 어떤 유형의 설계 변경에 유연한 대처가 가능한가? • 이 설계 패턴을 적용하지 않았을 때 발생하는 문제점은? • 이 설계 패턴을 적용하지 않고 • 좀 더 단순하고 쉽게 • 유연한 대처가 가능하도록 만들 수는 없는가?

Causes of redesign • Creating an object by specifying a class explicitly • 객체를 생성할 때 특정 클래스의 이름을 코드 상에서 구체적으로 지정한다면 향후 코드 변경에 어려움이 생긴다. • Dependence on specific operations • 특정 연산에 대한 요청을 하드코딩(hard-coding) 한다면, 연산의 유연성이 떨어진다.

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)

Causes of redesign • Algorithmic dependencies • S/W 시스템에 사용되는 algorithm은 자주 확장, 최적화, 대체를 통하여 변경된다. 변경되는 algorithm에 의존적인 object들 역시 변경될 가능성이 높다. • 자주 변경되는 algorithm 의 경우엔 다른 object들과 분리시키는 것이 바람직 • Tight coupling • 서로 강하게 연결된 class 들의 경우, 특정 class 하나가 변경되면 다른 class 들도 상당부분 변경되어야 한다. • 서로 강하게 연결된 class들은 이해하기 어렵고, 재사용하거나 유지하기 힘들다. • Coupling은 가능한 한 낮추는 것이 바람직

Causes of redesign • Extending functionality by subclassing • (구현)상속을 통한 기능확장의 경우 상속관계가 깊어지면 이해하기 힘들다. • Class 수가 많아져서 관리하기 어렵다. • (구현)상속보다는 delegation을 사용하는 것이 시스템을 유연하게 만드는 경우가 많다.

Causes of redesign • Inability to alter classes conveniently • 기존 시스템에서 작성된 class의 기능 일부를 수정하려면 일반적으로 소스코드가 필요. 상업적인 library를 도입하여 기존 소스코드를 구할 수 없거나 변경할 수 없다면? • 기존 class의 소스코드를 변경하지 않더라도, 해당 class가 맡은 역할의 동작을 수정할 수 있게 구조화 할 수 있다.

객체지향 설계 철학 • 역할별 분리 • 객체화, 모듈화 • 표준화 • 인터페이스 표준화 • 다형성 • 계층화 • 계층화 아키텍처

객체지향 설계 철학 • 역할별 분리 • 전체 로직을 한 덩어리로 만들지 않는다 • 로직을 역할별로 객체로 분리한다 • 각 객체는 단순 명료하게 요약될 수 있는 역할이 있어야 한다 • 그 객체의 메소드는 요약된 역할에 포함되는 일만 수행해야 한다 • 필요한 객체들을 선택하여 조립하여 전체 로직을 구현한다 • 표준화 • 객체들을 조립할 수 있으려면 • 객체들이 만나는 부분(인터페이스)의 표준이 필요하다 • 조립식 객체들은 이 표준을 준수해서 만들어져야 한다

객체지향 설계 철학 • 계층화 • 큰 어플리케이션의 로직은 3계층으로 나뉘는 것이 바람직 • 주요로직 계층, 단위 작업 계층, 유틸러티 계층 • 주요로직 계층 • 어플리케이션의 전체 로직의 흐름을 구현한다 • 단위 작업 계층의 메소드들을 호출하여 전체 로직을 구현한다 • 세부 로직을 구현하면 안된다 • 자료구조에 직접 접근하면 안된다 • 단위 작업 계층 • 어플리케이션의 세부 로직을 구현한다 • 자료구조에 직접 접근한다

객체지향 설계 철학 • 유틸러티 계층 • 어플리케이션과 무관한 유용한 공통 기능을 구현한다 • 예: linked list 와 같은 자료구조 클래스string 클래스, date time 클래스

재사용 단계 • 1단계: 유틸러티 계층의 재사용 클래스들을 확보 • 가장 손쉬운 재사용 • 상용 클래스 라이브러리들이 많다 • 적절한 클래스 라이브러리를 선택하여 구입하고 개발자들을 교육 훈련하면 됨 • 2단계: 단위 작업 계층의 재사용 클래스들을 확보 • 저절로 확보 되지 않음 • 바람직한 설계가 중요 • 재사용을 위한 설계가 필요 • 중요한 설계 철학: 역할별 분리, 계층화

재사용 단계 • 3단계: 주요로직 계층의 재사용 클래스들을 확보 • 가장 높은 단계의 재사용 • 설계 패턴에 대한 깊이 있는 공부가 필요 • 중요한 설계 철학: 역할별 분리, 계층화, 표준화 • 어플리케이션 프레임웍 (Application Framework) • 1단계 유틸러티 계층과 • 3단계 주요로직 계층(어플리케이션의 골격)의 • 재사용 클래스들이 갖춰짐

설계 패턴들에서 살펴볼 점 • 설계 변경에 어떻게 유연하게 대처하는가 • 이 설계 패턴은 어떤 종류의 설계 변경에 대한 대처인가 • 객체지향 설계 철학이 어떻게 반영되었는가 • 설계 철학을 반영하여 어떤 장점이 생겼는가 • 이 패턴을 사용하지 않고도 설계 변경 문제를 해결할 수는 없나? • 설계 변경에 대한 융통성을 약간 희생하는 대신 더 단순하게 설계할 수는 없는지 생각해 본다.

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