What is Design Patterns?- Gof Design Patterns -

Service InnovationService Innovation

Design Principles

Service InnovationService Innovation

33경영정보학과

Reality of SW world comparing with HW WorldReality of SW world comparing with HW World

SW World

HW World

Pluggable System

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)를 피할 수 없다면, 변화를 수용할 수

있도록 어떻게 디자인 프로세스를 변경할 것인가?

44경영정보학과

Business System Analysis and DesignBusiness 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.

MessageRequest

objects

55경영정보학과

Views on the Problem DomainViews 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.

Service Request

Service Response

Real World Viewwith Collaboration and delegation

Procedure-oriented View

Object-oriented View

Interacting objects

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.

66경영정보학과

How Humans work in Real World?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

Object-oriented View

Interacting objects

Service Request

Service Response

Real World Viewwith Collaboration and delegation

77경영정보학과

Maintainability Expandability / Portability / Modifiability / Readability / Flexibility

Service Request

Service Response

“do the Right Thing”Business System

Service-orientBusiness Process Innovation

Requirements

Interacting objects

“do the Thing Right”Information System

Component-basedPattern-orientedObject-oriented

Architecture / Design

Not what user Asked,Not what user Wanted,But what user Needed!

88경영정보학과

Problems of RequirementsProblems 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!

99경영정보학과

Problems of Debugging / MaintenanceProblems 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 effectsfrom the fix.

We really do not spend much time fixing bugs. The actual fix is relatively short!

1010경영정보학과

Design Principles to deal with Inevitable Changes.Design Principles to deal with Inevitable Changes.

“Designing from Context” Principle Be independent from other parts. Eliminate dependency to others.

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.Problem of Debugging/MaintenanceProblem of Debugging/MaintenanceProblem of Debugging/Maintenance

Finding where to fix.Avoiding Side-Effect.

Only one place to change!

RequirementsRequirementsRequirements

Always change. Change happens. Deal with it!

Object-orient

Design Patterns

CB Design

Service-orientedArchitecture

1111경영정보학과

““Designing from ContextDesigning from Context”” PrinciplePrinciple

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 high-

level 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.

1212경영정보학과

ObjectObject--orient Principlesorient Principles

Whenever possible, try to Encapsulate what variesEncapsulate what varies. Favor Aggregation/Composition Favor Aggregation/Composition over Inheritance. Program to InterfaceProgram 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.

1313경영정보학과

Design Principle RoundupDesign Principle Roundup

Using proven OO design principles result in more maintainable, flexible, and extensible software.

변화되는 것을 캡슐화 하라!

‘구현’보다는 ‘인터페이스(Super type)’에 맞춰 프로그래밍하라!

각 클래스는 단 한가지 일만 해야 한다.

클래스란 행위와 기능이다.

1414경영정보학과

Object-orient Design Principles

Principle #1

Principle #2

Principle #3

Principle #4

개방-폐쇄 원칙

단일 책임 원칙

리스코프 치환 원칙

복제금지 원칙

Gof Design Patterns

Service InnovationService Innovation

1616경영정보학과

ObjectObject--oriented Design isoriented 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.

1717경영정보학과

전문가들은전문가들은 어떻게어떻게 하나하나??

초보자들은 너무많은개념들과 이를실행할수있는다양한방법론에당황해서, 자신들이전에사용했던객체지향기술이아닌쪽으로되돌아갈수있다.

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.

1818경영정보학과

디자인디자인 패턴이패턴이 해결책해결책

누군가가 이미 여러분들이 고민하는 문제를 해결해 놓았습니다. 똑같은문제를경험했고, 그문제를해결했던 다른개발자들이익혔던지혜와교훈을

• 왜활용해야하는지?• 어떻게활용할수있는지?

1919경영정보학과

What is Design Patterns?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이렇게 하면 똑같은 방법을 두 번 반복하지 않은 채 ,이 해법을 백만 번 이상 재사용할 수 있다.

특별한 상황에서 일반적 설계 문제를 해결하기 위해 상호 교류하는 수정 가능한 객체와 클래스들에 대한 설명

재사용 가능한 객체지향 설계를 만들기 위해 유용한 공통의 설계 구조로부터 중요 요소들을 식별하여 이들에게 적당한 이름을 주고 추상화한 것

2020경영정보학과

Objective of PatternsObjective 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

Scope

Class(Static) Factory Method Adapter (Class)

Interpreter Template Method

Object(Dynamic)

Abstract FactoryBuilderPrototypeSingleton

Adapter (object)Bridge CompositeDecorator FaçadeFlyweight Proxy

Chain of ResponsibilityCommand, Iterator, Mediator, Memento, Observer StateStrategy Visitor

2121경영정보학과

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 thanclass inheritance.

• As that happen, emphasis shifts away from hard-coding a fixed set of behaviors towarddefining a smaller set of fundamental behaviors that can be composed into any number of more complex one.

Two recurring themes in Creational Patterns1) They all encapsulate knowledge about which concrete classes the system use.2) They hide how instances of these classes are created and put together.

Scope Design pattern Aspect(s) that can varyClass (Static) Factory Method 대행함수를 통한 객체 생성 문제

Object (Dynamic)

Abstract Factory 제품군별 객체 생성 문제Builder 부분 부분 생성을 통한 전체 객체 생성 문제Prototype 복제를 통한 객체 생성 문제Singleton 최대 N개로 객체 생성을 제한하는 문제

A Class Creational Pattern Object Creational Patterns

Uses inheritance to vary the class that’s instantiated Delegate instantiation to another object

2222경영정보학과

Structural PatternsStructural 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 Aspect(s) that can varyAdapter (Class/Object) 기존 모듈 재사용을 위한 인터페이스 변경 문제

Bridge 인터페이스와 구현의 명확한 분리 문제

Composite 부분-전체 관계 형성 및 관리 문제

Decorator 특정 객체의 기능 동적 추가, 삭제 문제

Facade 서브 시스템의 명확한 정의 문제

Flyweight 객체의 공유 문제

Proxy 대리 객체를 통한 작업 수행 문제

2323경영정보학과

Behavioral PatternsBehavioral 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.

Scope Design pattern Aspect(s) that can varyClass (Static)

Interpreter 간단한 문법에 기반한 검증 및 작업 처리 문제Template Method 알고리즘 기본 골격 재사용과 상세구현 변경 문제

Object(Dynamic)

Chain of Responsibility 수행 가능 객체까지 요청 전파 문제Command 수행할 작업의 일반화 문제Iterator 동일 자료형의 여러 객체에 대한 순차적 접근 문제Mediator M:N 객체 관계의 M:1 단순화 문제Memento 객체의 이전 상태 복원 문제Observer One source, multiple use 문제State 객체 상태 추가에 따른 행위 수행 변경 문제Strategy 동일 목적 알고리즘의 선택 적용 문제Visitor 작업 종류를 효율적으로 추가, 변경하는 문제

Behavioral Class Patterns Behavioral Object PatternsUse inheritance to distribute behavior between class. Use object composition rather than inheritance.

2424경영정보학과

Designing for ChangeDesigning 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.

2525경영정보학과

Design aspects that design patterns let you varyDesign aspects that design patterns let you vary

Purpose Design pattern Aspect(s) that can vary

Creational

Abstract Factory 제품군별 객체 생성 문제Builder 부분 부분 생성을 통한 전체 객체 생성 문제Factory Method 대행함수를 통한 객체 생성 문제Prototype 복제를 통한 객체 생성 문제Singleton 최대 N개로 객체 생성을 제한하는 문제

Structural

Adapter 기존 모듈 재사용을 위한 인터페이스 변경 문제Bridge 인터페이스와 구현의 명확한 분리 문제Composite 부분-전체 관계 형성 및 관리 문제Decorator 특정 객체의 기능 동적 추가, 삭제 문제Facade 서브 시스템의 명확한 정의 문제Flyweight 객체의 공유 문제Proxy 대리 객체를 통한 작업 수행 문제

Behavioral

Chain of Responsibility 수행 가능 객체까지 요청 전파 문제Command 수행할 작업의 일반화 문제Interpreter 간단한 문법에 기반한 검증 및 작업 처리 문제Iterator 동일 자료형의 여러 객체에 대한 순차적 접근 문제Mediator M:N 객체 관계의 M:1 단순화 문제Memento 객체의 이전 상태 복원 문제Observer One source, multiple use 문제State 객체 상태 추가에 따른 행위 수행 변경 문제Strategy 동일 목적 알고리즘의 선택 적용 문제Template Method 알고리즘 기본 골격 재사용과 상세구현 변경 문제Visitor 작업 종류를 효율적으로 추가, 변경하는 문제

2626경영정보학과

Design aspects that design patterns let you varyDesign aspects that design patterns let you vary

Purpose Design pattern Aspect(s) that can vary

Creational

Abstract Factory Families of product objectsBuilder How a composite object gets createdFactory Method Subclass of object that is instantiatedPrototype Class of object that is instantiatedSingleton The sole instance of a class

Structural

Adapter Interface to an objectBridge Implementation of an objectComposite Structure and composition of an objectDecorator Responsibilities of an object without subclassingFacade Interface to a subsystemFlywieght Storage costs of objectsProxy How an object is accessed; its location

Behavioral

Chain of Responsibility Object that can fulfill a requestCommand When and how a request is fulfilledInterpreter Grammar and interpretation of an languageIterator How an aggregate's elements are accessed, traversedMediator How and which objects interact with each otherMemento What private information is stored outside an object, and when

Observer Number of objects that depend on another object; how the dependent objects stay up to date

State State of an objectStrategy An algorithm,Template Method Steps of an algorithmVisitor Operations that can be applied to object(s) without changing their class(es)

2727경영정보학과

디자인디자인 패턴패턴 관계도관계도

Singleton Facade

Abstract Factory

Prototype

Factory MethodFactory Method

Template MethodTemplate Method

Strategy

Decorator

BuilderIterator

Memento AdapterAdapter

Proxy

BridgeCommand

Composite

Visitor

InterpreterInterpreter

Chain of reaction

ObserverMediatorState

Flyweight

Single instance

Single instance Implement using

often usesConfigure factory

dynamically

Complex dependency management

Adding operations

Defining the chainDefining

traversals

Sharing terminal symbols

Sharing states

Defining algorithm’s steps

Changing skin

versus guts

Sharing strategies

Adding responsibilities to

objects

Creating composites

Defininggrammar

Addingoperations

Enumeratingchildren

Saving state of iteration

Composed using

Avoiding hysteresis