E-1 설계 패턴 정리. E-2 GoF Pattern Catalog Creational Patterns –Abstract Factory –Prototype –Singleton –Factory Method –Builder Structural Patterns –Adapter.

Slides:



Advertisements
Similar presentations
4. 디자인패턴. 학습목표 디자인패턴의 이해  크리스토퍼 알렉산더  Each pattern describes a problem which occurs over and over again in our environment, and then describes.
Advertisements

디자인 패턴 UML II Group 유래성, 김윤환, 박성운. 도입  경험치가 높은 개발자 vs 경험치가 낮은 개발자  목적  사람들이 사용할 수 있는 / 하고 있는 ‘ 폼 ’ 에서 설계 경험을 얻어 낸다.  디자인 패턴엔 무엇인가 새로운 것이 있나 ?
A-1 A. 설계 패턴 (Design Pattern) 소개. A-2 설계 패턴이란 ? 설계패턴은 특정 문맥에서 일반적인 설계문제를 해결하도록 맞추어 진, 상호 협력하는 객체들과 클래스 들에 대한 기술 Design patterns are descriptions of communicating.
Java 로 배우는 디자인패턴 입문 Chapter 15. Facade 간단한 창구 덕성여자대학교 컴퓨터학부.
밥 팀 명 : TTL 조 팀 원 : 김정용 (PM) 서종규 노재현 엄성욱.
컴퓨터와 인터넷.
6.1 사용사례 6.2 객체 모델링 6.3 동적 모델링 6.4 시스템 설계 6.5 객체 설계 6.6 디자인 패턴
목 차 C# 언어 특징 .NET 프레임워크 C# 콘솔 프로그램 C# 윈도우 프로그램 실습 프로그래밍세미나 2.
클래스 class, 객체 object 생성자 constructor 접근 access 제어 이벤트 event 처리.
MS-Access의 개요 1강 MOS Access 2003 CORE 학습내용 액세스 응용 프로그램은 유용한 데이터를
최윤정 Java 프로그래밍 클래스 상속 최윤정
Ch.07-5 xml-rpc 사용하기 김상엽.
제 4 장 관계 학기 소프트웨어설계.
Java로 배우는 디자인패턴 입문 Chapter 5. Singleton 단 하나의 인스턴스
JAVA 언어로 배우는 디자인 패턴 입문 chap. 1-2.
Chatpter 05 상위 설계 01 설계의 이해 02 설계의 원리 03 소프트웨어 아키텍처 04 디자인 패턴 요약 연습문제.
제 6장. 생성자와 소멸자 학기 프로그래밍언어및실습 (C++).
5장 Mysql 데이터베이스 한빛미디어(주).
8.1 인터페이스 개요와 인터페이스 정의 8.2 인터페이스의 사용 8.3 인터페이스의 상속 8.4 인터페이스 참조
4장. 웹로직 서버상에서의 JDBC와 JTA의 운용
11장. 포인터 01_ 포인터의 기본 02_ 포인터와 Const.
FTP 프로그램 채계화 박재은 박수민.
SqlParameter 클래스 선문 비트 18기 발표자 : 박성한.
Error Detection and Correction
자바 5.0 프로그래밍.
모바일 자바 프로그래밍 JDBC / WAP Ps lab 오민경.
자료구조: CHAP 4 리스트 (3) 순천향대학교 컴퓨터공학과 하 상 호.
5장 Mysql 데이터베이스 한빛미디어(주).
자바 5.0 프로그래밍.
CHAP 12. 리소스와 보안.
1장. 데이터베이스 자료의 조직적 집합체_데이터베이스 시스템의 이해
7장 인터페이스와 추상 클래스.
Method & library.
자바 5.0 프로그래밍.
2장. 데이터베이스 관리 시스템 데이터베이스 관리 시스템의 등장 배경 데이터베이스 관리 시스템의 정의
STOPWATCH 박새별.
HTTP 프로토콜의 요청과 응답 동작을 이해한다. 서블릿 및 JSP 를 알아보고 역할을 이해한다.
Lesson 2. 기본 데이터형.
Chapter6 : JVM과 메모리 6.1 JVM의 구조와 메모리 모델 6.2 프로그램 실행과 메모리 6.3 객체생성과 메모리
15장 컬렉션 프레임워크 Section 1 컬렉션 프레임워크의 개요 Section 2 리스트 Section 3 셋
20장. 객체지향 프로그래밍 01_ 객체지향 프로그래밍의 시작.
제 4장. 객체 지향 프로그래밍 시작하기 학기 프로그래밍언어및실습 (C++).
Part 4 클래스 라이브러리 Chapter 10 : 다중 스레드 Chapter 11 : 패키지와 주요 클래스
자바 5.0 프로그래밍.
Power Java 제11장 상속.
20강 패턴을 통한 객체지향 언어의 이해 - II - 난이도 있는 패턴 예제 - I Lecturer Kim Myoung-Ho
데이터 베이스 DB2 관계형 데이터 모델 권준영.
15강. 폼 데이터 값 검증 Validator를 이용한 검증 ValidationUtils 클래스
14강. 세션 세션이란? 세션 문법 Lecturer Kim Myoung-Ho Nickname 블스
객체기반 SW설계 팀활동지 4.
균형이진탐색트리 이진 탐색(binary search)과 이진 탐색 트리(binary search tree)와의 차이점
알고리즘 알고리즘이란 무엇인가?.
클러스터 시스템에서 효과적인 미디어 트랜스코딩 부하분산 정책
클래스 : 기능 CHAPTER 7 Section 1 생성자(Constructor)
.Net Web Application 2007 컴퓨터공학실험(Ⅰ)
3장 JSP프로그래밍의 개요 이장에서 배울 내용 : JSP페이지의 기본적인 개요설명과 JSP페이지의 처리과정 그리고 웹 어플리케이션의 구조에 대해서 학습한다.
제 8장. 클래스의 활용 학기 프로그래밍언어및실습 (C++).
Lecture 04 객체지향 페러다임 Kwang-Man Ko
01. 분산 파일 시스템의 개요 네트워크에 분산된 파일을 사용자가 쉽게 접근하고 관리할 수 있게 해준다.
JSP Programming with a Workbook
학습내용 프로토콜 계층화 OSI 모델의 용어 및 기능 개체 서비스 접근점 (N) 프로토콜과 (N) 서비스 서비스 프리미티브
발표자 : 이지연 Programming Systems Lab.
.Net FrameWork for Web2.0 한석수
2.가상머신의 탐험 도구, Oolong에 대하여 ps lab 김윤경.
1장 C 언어의 개요 C 언어의 역사와 기원 C 언어의 특징 프로그램 과정 C 프로그램 구조 C 프로그램 예제.
29장. 템플릿과 STL 01_ 템플릿 02_ STL.
 6장. SQL 쿼리.
M.B.TEAM 중간 발표 (5.18) 이 제걸 백 인호.
7 생성자 함수.
6 객체.
Presentation transcript:

E-1 설계 패턴 정리

E-2 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

E-3 The Catalog of Design Patterns Abstract Factory – 구체적인 클래스를 미리 정하지 않고, 상호 관련 있는 객체들의 패 밀리 (family) 를 생성하는 인터페이스를 제공한다. Adapter – 기존 클래스의 인터페이스를 사용자가 원하는 다른 인터페이스로 변환함으로써, 서로 다른 인터페이스 때문에 상호연동을 못하는 클래스들을 연동될 수 있도록 해준다. Bridge – 시스템의 클래스들을 구현부분과 추상부분으로 분리하여 설계함 으로써 두 부분이 상호 독립적으로 바뀔 수 있도록 한다. Builder – 복잡한 객체를 생성하는 부분과 객체 표현부분을 분리함으로써, 서로 다른 객체 표현부분들을 생성하더라도 동일한 객체 생성부 분을 이용할 수 있게 한다.

E-4 The Catalog of Design Patterns Chain of Responsibility – 서비스 제공자들을 체인형태로 달아둠으로써, 서비스 요청자와 서비스 제공자의 결합도 (coupling) 를 약화시키고, 복수개의 서비 스 제공자를 들 수 있다. Command – 소프트웨어 내에서 발생할 수 있는 명령을 객체화시킴으로써, 명 령을 기록하거나 명령을 수행하기 전 상태로 소프트웨어 상태를 복구할 때 이용할 수 있다. Composite – 부분 - 전체 구조 (Part-Whole Hierarchy) 를 표현하기 위하여 객체들 을 트리구조로 구성한다. 이를 통하여 사용자가 개별적 객체나 복 합적 객체를 동일하게 다룰 수 있다.

E-5 The Catalog of Design Patterns Decorator – 한 객체에 대해서 동적으로 책임사항들 (Responsibilities) 을 덧붙 일 수 있다. 이를 통하여 기능확장을 위한 서브클래싱 (Subclassing) 과 같은 효과를 거둘 수 있다. Façade – 서브시스템 안의 여러 인터페이스들에 대하여 통합된 인터페이스 를 제공한다. 제공되는 인터페이스를 통하여 서브시스템의 기능 을 쉽게 사용할 수 있다. Factory Method – 생성되는 객체에 대한 결정을 서브클래스가 할 수 있도록 객체 생 성인터페이스를 제공한다.

E-6 The Catalog of Design Patterns Flyweight – 수많은 작은 객체들에 대해서 효율적인 공유기능을 제공한다. Interpreter – 특정언어에 관한 문법 표현을 정의한다. 정의된 표현은 해당 언어 의 문장을 해석하는데 이용된다. Iterator – 자료구조의 내부적 표현과 상관없이, 저장되어 있는 자료요소들 을 순차적으로 접근할 수 있는 방법을 제공한다. Mediator – 객체들의 상호 작용을 캡슐화하는 객체를 정의한다. 이를 통하여 객체들 간의 커플링을 줄일 수 있으며, 각 상호 작용을 독립적으로 변경할 수 있다.

E-7 The Catalog of Design Patterns Memento – 객체지향의 캡슐화 원칙을 어기지 않으면서, 객체의 내부 상태정 보들을 찾아내어 외부 객체화한다. 객체화된 상태정보는, 원 객체 의 상태복구에 이용될 수 있다. Observer – 한 객체의 상태에 변화가 일어나면, 해당 객체의 상태에 관심 있는 모든 다른 객체들에게 자동으로 변화가 발생한 사실을 알려준다. 즉 객체들간의 일 - 대 - 다 (one-to-many) 관계를 표현한다. Prototype – 원형 (prototypical) 객체를 복사하는 방식으로 객체를 생성한다. 이 를 통하여 생성하는 객체의 종류를 동적으로 지정할 수 있다.

E-8 The Catalog of Design Patterns Proxy – 특정 객체에 대한 접근을 관리하기 위하여 해당 객체의 대리자 (surrogate) 를 만든다. Singleton – 특정 클래스의 객체가 단 하나만 생성되도록 보장하며, 그 객체에 대한 전역 접근이 가능하도록 해준다. State – 객체의 상태정보가 변함에 따라, 마치 객체의 클래스가 변하는 것 처럼, 객체의 행동도 바뀌도록 해준다. Strategy – 알고리즘을 객체화하여 여러 알고리즘을 동적으로 교체가능 하도 록 만든다. 알고리즘을 이용하는 클라이언트 코드와는 상관없이 알고리즘을 다양하게 바꿀 수 있다.

E-9 The Catalog of Design Patterns Template Method – 연산에 있어서 전체 알고리즘의 윤곽만 기술한 다음, 알고리즘의 특정 부분의 구현을 서브클래스로 맡긴다. 이를 통하여 전체 알고 리즘의 구조를 변화시키지 않으면서 서브클래스가 알고리즘의 특 정부분을 쉽게 변경시킬 수 있다. Visitor – 자료구조 내에 있는 객체 요소들에게 특정 연산을 수행하고자 원 할 때 이용한다. Visitor 는 연산 수행의 대상이 되는 객체들의 클래 스를 바꾸지 않고도 새로운 연산을 추가할 수 있도록 도와준다.

E-10 설계패턴이 지원하는 변경사항들 PurposeDesign PatternAspect(s) that can vary Creational Abstract FactoryFamilies of product objects BuilderHow a composite object gets created Factory MethodSubclass of object that is instantiated PrototypeClass of object that is instantiated SingletonThe sole instance of a class Structural AdapterInterface to an object BridgeImplementation of an object CompositeStructure and composition of an object DecoratorResponsibilities of an object without subclassing FaçadeInterface to a subsystem FlyweightStorage costs of objects ProxyHow an object is accessed; its location

E-11 설계패턴이 지원하는 변경사항들 PurposeDesign PatternAspect(s) that can vary behavioral Chain of responsibility Object that can fulfill a request CommandWhen and how a request is fulfilled InterpreterGrammar and interpretation of a language IteratorHow an aggregate’s elements are accessed, traversed MediatorHow and which objects interact with each other MementoWhat private information is stored outside an object, and when ObserverNumber of objects that depend on another object; how the dependent objects stay up to date StateStates of an object StrategyAn algorithm Template MethodSteps of an algorithm VisitorOperations that can be applied to objects without changing their class(es)

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

E-13 Causes of redesign Dependence on hardware and software platform – 특정 플랫폼에 의존적인 Software 는 다른 플랫폼으로 이전하기 힘들다. –Software 의 플랫폼 의존성을 줄이는 것이 바람직하다. –Sol> Abstract Factory, Bridge pattern Dependence on object representations or implementations – 만일 client code 가 특정 object 의 표현방식과 저장방식, 그리고 위치 등을 알아야 된다면, 해당 object 에 변경이 이루어 질 때마다 client code 부분도 변경이 이루어져야 한다. –Client code 부분으로 부터 서비스하는 object 의 내부 정보를 숨 기는 것이 바람직하다. (low coupling) –Sol> Abstract Factory, Bridge, Mememto, Proxy

E-14 Causes of redesign Algorithmic dependencies –S/W 시스템에 사용되는 algorithm 은 자주 확장, 최적화, 대체를 통 하여 변경된다. 변경되는 algorithm 에 의존적인 object 들 역시 변 경될 가능성이 높다. – 자주 변경되는 algorithm 의 경우엔 다른 object 들과 분리시키는 것이 바람직 –Sol> Builder, Iterator, Strategy, Template Method, Visitor Tight coupling – 서로 강하게 연결된 class 들의 경우, 특정 class 하나가 변경되면 다른 class 들도 상당부분 변경되어야 한다. – 서로 강하게 연결된 class 들은 이해하기 어렵고, 재사용하거나 유 지하기 힘들다. –Coupling 은 가능한 한 낮추는 것이 바람직 –Sol> Abstract Factory, Bridge, Chain of Responsibility, Command, Façade, Mediator, Observer

E-15 Causes of redesign Extending functionality by subclassing –( 구현 ) 상속을 통한 기능확장의 경우 상속관계가 깊어지면 이해하 기 힘들다. –Class 수가 많아져서 관리하기 어렵다. –( 구현 ) 상속보다는 delegation 을 사용하는 것이 시스템을 유연하게 만드는 경우가 많다. –Sol> Bridge Chain of Responsibility, Composite, Decorator, Observer, Strategy

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