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 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, …

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 패턴

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