Microsoft PowerPoint - Gof - What is Design Patterns - Gof Design Pattterns

Size: px

Start display at page:

Download "Microsoft PowerPoint - Gof - What is Design Patterns - Gof Design Pattterns"

설아 서
8 years ago
Views:

1 What is Design Patterns? - Gof Design Patterns - Service Innovation

2 Design Principles Service Innovation

3 Reality of SW world comparing with HW World How can we implement complex, abstract, and dynamic real world in software? 복잡하고 추상적이며 역동적인 현실세계를 어떻게 software로 구현할까? Change is inevitable! So change development process so that we can address change more effectively. 변화(change)를 피할수없다면, 변화를 수용할 수 있도록 어떻게 디자인 프로세스를 변경할 것인가? SW World Pluggable System HW World 3

4 Business System Analysis and Design Business System Analysis: do the Right Thing Emphasize an investigation of the problem and requirements, rather than a solution. Requirements analysis: an investigation of the requirements or Object-oriented analysis: an investigation of the domain objects Design: do the Thing Right Emphasizes a conceptual solution (in software and hardware) that fulfills the requirements, rather than its implementation. objects Request Message 4

Requirements analysis: an investigation of the requirements or Object-oriented analysis: an investigation of the

5 Views on the Problem Domain We model the system a number of objects that interact / collaborate. Object orientation is ideally suited to creating models of real systems. Procedure-oriented View Real World View with Collaboration and delegation Object-oriented View Service Request Interacting objects Service Response Objects communicate with requests. A request is a message specifying that an indicated operation be carried out using one or more objects and, optionally, returning a result. 5

Procedure-oriented View Real World View with Collaboration and delegation Object-oriented View Service Request Interacting

6 How Humans work in Real World? Service-orient Abstraction Information Hiding Encapsulation Collaboration Single Responsibility Principle Your objects only one reason to change. Decomposition, Top-down Cohesion / Coupling Interface Delegation Shift Responsibility Aggregation Polymorphism Dynamic Real World View with Collaboration and delegation Service Request Service Response Object-oriented View Interacting objects 6

7 Maintainability Expandability / Portability / Modifiability / Readability / Flexibility do the Right Thing Business System Service Request Not what user Asked, Not what user Wanted, But what user Needed! do the Thing Right Information System Interacting objects Service Response Service-orient Business Process Innovation Requirements Component-based Pattern-oriented Object-oriented Architecture / Design 7

do the Thing Right Information System Interacting objects Service Response Service-orient Business

8 Problems of Requirements The Nature of Requirements, illogic of Business Rules Requirements are incomplete. Requirements are usually wrong. Requirements (and users) are misleading. Requirements do not tell the whole story;. Requirements always change. The user s view of their needs changes. The developer s view of the user s problem domain changes The environment in which the software is being developed changes. Moving target problem While the information system is being developed, the requirements change. Change happens! Deal with it. Rather than complaining about changing requirements, we should change the development process so that we can address change more effectively. We may not know what will change, but I can guess where! 8

The developer s view of the user s problem domain changes The environment in which the software is being developed changes.

9 Problems of Debugging / Maintenance Changing a function, or even data used by a function, can weak havoc on other function The overwhelming amount of time involved in maintenance and debugging is spent on trying to discover how the code works and finding and taking the time to avoid unwanted side effects. The devil is in the Side-Effects A focus on functions is likely to cause side effects that are difficult to find. Most of time spent in maintenance and debugging is not spent on fixing bugs, but in finding them and seeing how to avoid unwanted side effects from the fix. We really do not spend much time fixing bugs. The actual fix is relatively short! 9

The devil is in the Side-Effects A focus on functions is likely to cause side effects that are difficult to find.

10 Design Principles to deal with Inevitable Changes. Designing from Context Principle Be independent from other parts. Eliminate dependency to others. Requirements Requirements Always change. Service-oriented Architecture CB Design Design Patterns Object-orient Problem Problem of of Debugging/Maintenance Finding where to fix. Avoiding Side-Effect. Change happens. Deal with it! Open for Extension but Close for Modification. Find what varies and Encapsulate it! Loosely Coupled Design only one reason to change. Only talk to your immediate friends. Depend on Abstraction. Program to Interface, not Implementation. Don t call us, we ll call you. Favor Aggregation over Inheritance. Only one place to change! 10

Avoiding Side-Effect. Change happens. Deal with it! Open for Extension but Close for Modification. Find what varies and Encapsulate it!

11 Designing from Context Principle Design from Context, to create the big picture before designing the details. Start with a service-orientation. Define the services at an abstract level. Dependency Inversion Principle High-level modules should not depend on low-level modules. Both highlevel modules and low-level modules should depend upon abstraction. Abstraction should not depend on details. Details should depend upon abstraction. Complexification The process of starting at the simplest (Conceptual) level and gradually adding details and features, making the design more complex as you go deeper. 11

Both highlevel modules and low-level modules should depend upon abstraction. Abstraction should not depend on details.

12 Object-orient Principles Whenever possible, try to Encapsulate what varies. Favor Aggregation/Composition over Inheritance. Program to Interface, not Implementation. The Open-Close Principle (OCP) Classes should be Open for Extension but Close for Modification. Single Responsibility Principle (SRP) A class should have only one reason to change. The Power of Loose Coupling Principle Strive for loosely coupled designs between objects that interact. Least knowledge Principle (LKP) Only talk to your immediate friends. Dependency Inversion Principle Depend on Abstractions. Do not depend on concrete classes. Hollywood Principle Don t call us, we ll call you. 12

Single Responsibility Principle (SRP) A class should have only one reason to change.

13 Design Principle Roundup Using proven OO design principles result in more maintainable, flexible, and extensible software. 변화되는 것을 캡슐화 하라! 구현 보다는 인터페이스(Super type) 에 맞춰 프로 그래밍하라! 각 클래스는 단 한가지 일만 해야 한다. 클래스란 행위와 기능이다. 13

14 Object-orient Design Principles Principle #1 개방-폐쇄 원칙 Principle #2 복제금지 원칙 Principle #3 단일 책임 원칙 Principle #4 리스코프 치환 원칙 14

15 Gof Design Patterns Service Innovation

16 Object-oriented Design is Designing object-oriented software is hard. Designing reusable object-oriented software is even harder. You must find pertinent objects, factor them into classes at right granularity define class interface and inheritance hierarchies, and establish key relationships among them. Your design should be specific to the problem at hand, but also general enough to address future problems and requirements avoid redesign, or at least minimize it. 16

You must find pertinent objects, factor them into classes at right granularity define class interface and inheritance

17 전문가들은 어떻게 하나? 초보자들은 너무 많은 개념들과 이를 실행할 수 있는 다양한 방법론에 당황해서, 자신들이 전에 사용했던 객체지향 기술이 아닌 쪽으로 되돌아갈 수 있다. One thing expert designers know not to do is solve every problem from first principles. Rather, they reuse solutions that have worked for them in the past. When they find a good solution, they use it again and again. Such experience is part of what makes them expert. 17

One thing expert designers know not to do is solve every problem from first principles.

18 디자인 패턴이 해결책 누군가가 이미 여러분들이 고민하는 문제를 해결해 놓았습니다. 똑같은 문제를 경험했고, 그 문제를 해결했던 다른 개발자들이 익혔던 지혜와 교훈을 왜 활용해야 하는지? 어떻게 활용할 수 있는지? 18

19 What is Design Patterns? Each pattern describes Describes a problem which occurs over and over again in our environment, 기존 환경 내에서 반복적으로 일어나는 문제를 설명하고, And then describes the core of the solution to that problem. 그 문제들에 대한 해법의 핵심을 설명하는 것이다. In such a way that you can use this solution a million times over, without ever doing it the same way twice 이렇게 하면 똑같은 방법을 두 번 반복하지 않은 채,이 해법을백만번이상재사용할수있다. 특별한 상황에서 일반적 설계 문제를 해결하기 위해 상호 교류하는 수 정 가능한 객체와 클래스들에 대한 설명 재사용 가능한 객체지향 설계를 만들기 위해 유용한 공통의 설계 구조 로부터 중요 요소들을 식별하여 이들에게 적당한 이름을 주고 추상화 한것 19

then describes the core of the solution to that problem. 그 문제들에 대한 해법의 핵심을 설명하는 것이다.

20 Objective of Patterns Creational Patterns: abstract the instantiation process. help make a system independent of how its object are created, composed, and represented. gives you a lot of flexibility in what gets created, who creates it, how it gets created, and when. Structural Pattern: are concerned with how classes and objects are composed to form larger structure. Behavioral Patterns: are concerned with algorithms and the assignment of responsibilities between objects. shift your focus away from flow of control to let you concentrate just on the way objects are interconnected. Objective Creation Structure Behavior S c o p e Class (Static) Object (Dynamic) Factory Method Abstract Factory Builder Prototype Singleton Adapter (Class) Adapter (object) Bridge Composite Decorator Façade Flyweight Proxy Interpreter Template Method Chain of Responsibility Command, Iterator, Mediator, Memento, Observer State Strategy Visitor 20

21 Creational Patterns Creational Patterns: abstract the instantiation process. help make a system independent of how its object are created, composed, and represented. gives you a lot of flexibility in what gets created, who creates it, how it gets created, and when. become important as systems evolve to depend more on object composition than class inheritance. As that happen, emphasis shifts away from hard-coding a fixed set of behaviors toward defining a smaller set of fundamental behaviors that can be composed into any number of more complex one. Two recurring themes in Creational Patterns 1) They all encapsulate knowledge about which concrete classes the system use. 2) They hide how instances of these classes are created and put together. A Class Creational Pattern Uses inheritance to vary the class that s instantiated Object Creational Patterns Delegate instantiation to another object Scope Design pattern Aspect(s) that can vary Class (Static) Factory Method 대행함수를 통한 객체 생성 문제 Abstract Factory 제품군별 객체 생성 문제 Object (Dynamic) Builder 부분 부분 생성을 통한 전체 객체 생성 문제 Prototype 복제를 통한 객체 생성 문제 Singleton 최대 N개로 객체 생성을 제한하는 문제 21

22 Structural Patterns 구조 패턴 (Structural Pattern) are concerned with how classes and objects are composed to form larger structures. Structural Class Pattern (Static fixed at compile time) Use inheritance to compose interfaces or implementations. Structural object patterns (dynamic can be changed at runtime) Rather than compositing interfaces or implementations, structural object patterns describe ways to compose objects to realize new functionality. The added flexibility of object composition comes from the ability to change the composition at run-time, which is impossible with static class composition. Design pattern Adapter (Class/Object) Bridge Composite Decorator Facade Flyweight Proxy Aspect(s) that can vary 기존 모듈 재사용을 위한 인터페이스 변경 문제 인터페이스와 구현의 명확한 분리 문제 부분-전체 관계 형성 및 관리 문제 특정 객체의 기능 동적 추가, 삭제 문제 서브 시스템의 명확한 정의 문제 객체의 공유 문제 대리 객체를 통한 작업 수행 문제 22

23 Behavioral Patterns Behavioral Patterns are concerned with algorithms and the assignment of responsibilities between objects. describe not just patterns of objects or classes but also the patterns of communication between them. characterize complex control flow that s difficult to follow at run-time. shift your focus away from flow of control to let you concentrate just on the way objects are interconnected. Behavioral Class Patterns Use inheritance to distribute behavior between class. Behavioral Object Patterns Use object composition rather than inheritance. Scope Design pattern Aspect(s) that can vary Class Interpreter 간단한 문법에 기반한 검증 및 작업 처리 문제 (Static) Template Method 알고리즘 기본 골격 재사용과 상세구현 변경 문제 Object (Dynamic) Chain of Responsibility Command Iterator Mediator Memento Observer State Strategy Visitor 수행 가능 객체까지 요청 전파 문제 수행할 작업의 일반화 문제 동일 자료형의 여러 객체에 대한 순차적 접근 문제 M:N 객체 관계의 M:1 단순화 문제 객체의 이전 상태 복원 문제 One source, multiple use 문제 객체 상태 추가에 따른 행위 수행 변경 문제 동일 목적 알고리즘의 선택 적용 문제 작업 종류를 효율적으로 추가, 변경하는 문제 23

24 Designing for Change To design the system so that it s robust to such changes, You must consider how the system might need to change over its lifetime. A design that doesn t take change into account risks major redesign in the future. Design patterns Help you avoid this by ensuring that a system can change in specific ways. Each design pattern lets some aspect of system structure vary independently of other aspects, thereby making a system more robust to a particular kind of change. Some common causes of redesign Creating an object by specifying a class explicitly. Dependence on specific operations. Dependence on hardware and software platform. Dependence on object representations or implementations. Algorithmic dependencies. Tight coupling. Extending functionality by subclassing. Inability to alter classes conveniently. 24

25 Design aspects that design patterns let you vary Purpose Design pattern Aspect(s) that can vary Creational Structural Behavioral Abstract Factory Builder Factory Method Prototype Singleton Adapter Bridge Composite Decorator Facade Flyweight Proxy Chain of Responsibility Command Interpreter Iterator Mediator Memento Observer State Strategy Template Method Visitor 제품군별 객체 생성 문제 부분 부분 생성을 통한 전체 객체 생성 문제 대행함수를 통한 객체 생성 문제 복제를 통한 객체 생성 문제 최대 N개로 객체 생성을 제한하는 문제 기존 모듈 재사용을 위한 인터페이스 변경 문제 인터페이스와 구현의 명확한 분리 문제 부분-전체 관계 형성 및 관리 문제 특정 객체의 기능 동적 추가, 삭제 문제 서브 시스템의 명확한 정의 문제 객체의 공유 문제 대리 객체를 통한 작업 수행 문제 수행 가능 객체까지 요청 전파 문제 수행할 작업의 일반화 문제 간단한 문법에 기반한 검증 및 작업 처리 문제 동일 자료형의 여러 객체에 대한 순차적 접근 문제 M:N 객체 관계의 M:1 단순화 문제 객체의 이전 상태 복원 문제 One source, multiple use 문제 객체 상태 추가에 따른 행위 수행 변경 문제 동일 목적 알고리즘의 선택 적용 문제 알고리즘 기본 골격 재사용과 상세구현 변경 문제 작업 종류를 효율적으로 추가, 변경하는 문제 25

26 Design aspects that design patterns let you vary Purpose Design pattern Aspect(s) that can vary Abstract Factory Families of product objects Builder How a composite object gets created Creational Factory Method Subclass of object that is instantiated Prototype Class of object that is instantiated Singleton The sole instance of a class Adapter Interface to an object Bridge Implementation of an object Composite Structure and composition of an object Structural Decorator Responsibilities of an object without subclassing Facade Interface to a subsystem Flywieght Storage costs of objects Proxy How an object is accessed; its location Chain of Responsibility Object that can fulfill a request Command When and how a request is fulfilled Interpreter Grammar and interpretation of an language Iterator How an aggregate's elements are accessed, traversed Mediator How and which objects interact with each other Memento What private information is stored outside an object, and when Behavioral Observer Number of objects that depend on another object; how the dependent objects stay up to date State State of an object Strategy An algorithm, Template Method Steps of an algorithm Visitor Operations that can be applied to object(s) without changing their class(es) 26

27 디자인 패턴 관계도 Decorator Changing skin versus guts Builder Creating composites Strategy Prototype Singleton Adding responsibilities to objects Sharing strategies State Saving state of iteration Iterator Flyweight Sharing states Composite Defining algorithm s steps Configure factory dynamically Single instance Interpreter Abstract Factory Single instance Enumerating children Memento Sharing terminal symbols Adding operations Defining grammar Template Method Facade Visitor Avoiding hysteresis Composed using Defining traversals Adding operations Mediator Implement using Command often uses Adapter Bridge Proxy Chain of reaction Complex dependency management Defining the chain Observer Factory Method 27

<C0DAB7E120C7D5BABB2E687770>

<C0DAB7E120C7D5BABB2E687770> 제5회 SW공학 Technical 세미나 패턴 저자와 함께하는 패턴이야기 세부 프로그램 시 간 내 용 강사진 13:30 ~ 14:00 등 록 14:00 ~ 14:05 인사말 14:05 ~ 15:00 15:00 ~ 15:30 15:30 ~ 17:00 o 미워도 다시 보는 패턴이야기 - SW 설계의 패턴과 다양한 패턴의 주제 소개 - 패턴의 3박자와 패턴으로