Command

Command – 의도 undo 기능을 구현하려면? 전달된 순서가 아닌, 우선순위별로 명령을 실행하려면? 명령이 발생하자마자 즉시 실행하는 것이 아니고 명령 대기 큐에 넣어졌다가 나중에 실행되어야 한다면? 매크로 기능을 구현하려면? 메뉴와 툴바 버튼을 사용자가 변경할 수 있으려면?

Command - 해결 명령을 객체로 구현한다. 요청이 발생하자마자 즉시 실행하는 것이 아니고 요청이 발생하면 명령 객체를 만들어 전달한다 명령 객체는 대기 큐나, 우선 순위 큐에 넣어 순서대로 꺼내어 실행할 수 있다

Command - 구조

Command - 구조 표준을 준수하는 일련의 명령 객체들이 만들어진다 명령 객체들은 표준을 준수하므로 동일하게 다뤄질 수 있다

Command - 구조

Command - 구조 명령 객체는 개별적인 상황에서 각자 생성되지만 일단 생성되고 나면 명령 객체들은 priority queue, undo stack, redo stack 에서 동일하게 다뤄진다

Command - 구조 명령을 실행해야 할 상황이 발생하면 명령 객체를 만들어 priority queue 에 넣는다 명령을 실행한다 실행된 명령 객체는 undo stack 에 넣는다 undo 가 요청되면 undo stack 에서 명령을 꺼내어 undo 를 실행 undo 를 실행한 명령 객체는 redo stack 에 넣는다

Command - 구조

Command - 구조 앞 슬라이드는 매크로 명령을 구현한 구조이다 MacroCommand 도 Command 표준을 준수한다 어떤 패턴인가?

Command - 구조

Command - 결과 command 패턴은 다양한 상황에서 응용될 수 있다 앞 슬라이드에서 우선 순위 큐는 thread safe 하게 구현되어야 한다

Mediator

Mediator – 의도 여러 객체들간 상호작용을 하나의 객체에 몰아서 구현한다 나머지 객체들이 단순해져서 재사용성이 증가한다 상호작용이 한 곳에 모아져 있으므로 이해하고 수정하는데 좋다

Mediator - 의도 파일 선택 대화상자 파일을 선택할 수 있는 리스트 박스 파일 이름을 입력할 수 있는 텍스트 박스 확인 버튼 텍스트 박스에 파일 이름을 입력하면 알파벳이 눌러질 때마다 리스트 박스는 저절로 스크롤 되어 해당 파일이 선택된다 확인 버튼은 활성화된 상태가 된다

Mediator - 의도 리스트 박스에서 파일을 선택하면 텍스트 박스에 그 파일 이름이 저절로 입력된다 확인 버튼은 활성화된 상태가 된다

Mediator - 의도 이 기능을 어디에 구현하는 것이 좋을까? 텍스트 박스가 직접 리스트 박스의 항목을 선택하고 버튼을 활성화 해야하나?

Mediator - 의도 언제나 하나의 세트로 같이 몰려 다니는 객체들의 경우 객체들이 서로 참조하고 직접 상호작용해도 된다. 재사용성이 나빠지지 않는다 그렇지 않은 경우에는 객체들이 서로 참조하고 직접 상호작용하는 것은 바람직하지 않다 재사용성이 나빠진다

구조1

구조1 텍스트 박스가 변경된 경우

구조1 리스트 박스가 변경된 경우

구조2

구조2 텍스트 박스가 변경된 경우

구조2 리스트 박스가 변경된 경우

실습: 구조1과 구조2의 장단점을 비교해 봅시다

Abstract Factory

Abstract Factory - 의도 작업을 하는데 한 세트의 도구가 필요하다 예를들어 그림을 그리는데 한 세트의 도구가 필요하다 도화지, 물감, 팔레트, 붓 수채와, 유화, 포스터화 도구 세트가 따로 있다 그림 그리는 절차는 같다

Abstract Factory - 의도 그림 그리는 절차는 같으므로 재사용 가능한 코드로 구현하여 공유한다 도구 세트는 경우에 따라 다르다 abstract factory로 구현한다 재사용 가능한 공통적인 부분과 경우에 따라 달라지는 부분의 분리가 목적

Abstract Factory - 의도 ‘Motif’ 나 ‘Presentation Manager’ 와 같은 여러가지 look-and-feel 표준을 지원해야 하는 에디터를 개발한다고 생각해 보자 에디터 코드의 상당 부분은 공통적이다 에디터 모듈에서 Motif 의 widget을 직접 생성한다면 그 에디터는 Motif 에 종속적이게 된다 Unix 의 X window 에서는 메뉴, 스크롤바, 버튼과 같은 사용자 인터페이스 요소를 widget 이라고 한다 widget 생성 코드를 뺀 나머지 에디터 코드는 재사용 가능하다 구체적인 widget 생성 코드를 에디터 모듈에서 분리해야 에디터 모듈의 재사용성이 높아진다

Abstract Factory - 해결 widget을 생성하는 코드를 에디터 모듈에서 분리하여 별도의 클래스로 구현한다  factory class 역할이 오로지 객체를 생성하는 것뿐인 클래스  factory class 필요한 만큼 factory class 들이 만들어진다 motif widget factory class PM widget factory class OpenLook widge factory class

Abstract Factory - 해결 앞의 factory class 들의 공통 부모 클래스가 필요하다 공통 부모 클래스는 메소드를 구현할 필요는 없다 메소드의 선언만 표준화 하면 된다  abstract class abstract class 구현은 없고 선언만 있는 abstract method 하위 클래스가 abstract method 들을 반드시 구현하도록 강제함 factory class + abstract class  abstract factory class

Abstract Factory - 구조 << interface >> << interface Button GUIFactory + draw () + createButton () + createScrollbar () WinButton OSXButton + draw () + draw () WinGUIFactory OSXGUIFactory + createButton () + createButton () + createScrollbar () + createScrollbar () << interface >> Scrollbar + draw () WinScrollbar OSXScrollbar + draw () + draw ()

Abstract Factory - 해결 필요에 따라 WinGUIFactory, OSXGUIFactory 객체를 생성하여 에디터 모듈(client)에 넘기면 에디터 모듈은 이 객체를 받아서 필요한 컨트롤을 생성 에디터 모듈에 전달된 factory 객체가 무엇이냐에 따라 그 클래스의 메소드가 호출됨  polymorphism

Abstract Factory - 해결 Abstract factory class 객체를 생성하기 위한 메소드들의 선언을 정의한다 abstract factory method factory class abstract factory class 를 상속받는다 abstract factory method 들을 전부 구현한다 factory method 는 객체를 생성하여 리턴한다

Abstract Factory - polymorphism factory class 들의 사용법은 동일 클라이언트 코드는 abstract factory class 와 그 메소드만 참조하여 구현 가능 실행될 때 클라이언트에 전달되는 factory class 객체가 무엇이냐에 따라 그 클래스의 메소드가 호출됨 새로운 factory class가 추가되어도 클라이언트 코드는 변경될 필요 없음

Abstract Factory - 해결 좋은 설계인가? 재사용 가능한 공통적인 부분의 분리가 잘되었는가? 새로운 widget set를 추가할 때 변경되는 코드는?

Abstract Factory - 기타 factory class 는 singleton 패턴을 적용하기에 알맞다 prototype 패턴을 적용하면 factory class의 수를 줄일 수 있음

Prototype – 응용 Prototype 패턴을 Abstract Factory 패턴에 적용하면 factory class 의 수를 줄일 수 있다 어떻게??

Bridge

Bridge - 의도 high level operation 과 low level operation 의 분리 구현 예: 사진 장식 어플리케이션에서 high level operation : 장식효과 사진에 경계선 효과 넣기 사진에 copyright 텍스트 넣기 사진에 말 풍선 넣기 low level operation : 사진 파일 다루기 jpeg 그림에 선 그리기 gif 그림에 문자 출력하기 bmp 파일 읽어오기/저장하기

Bridge - 의도 사진에 말 풍선을 넣기 장식 효과의 절차 사진 파일을 읽는다 말 풍선의 선을 그린다 말 풍선 내부를 칠한다 텍스트를 출력한다 사진 파일을 저장한다 세부 스텝 구현은 사진 파일의 종류에 따라 다르다 jpeg, gif, bmp ...

Bridge - 의도 말 풍선 넣기 같은 장식 효과를 클래스로 구현할 때 파일의 종류 마다 클래스로 따로 구현해야 하나? jpeg에 말 풍선 넣기 클래스, gif에 말 풍선 넣기 클래스 ... jpeg에 경계선 효과 클래스, gif에 경계선 효과 클래스 ... 구현할 클래스의 수 = 장식 효과 종류의 수 x 사진 파일의 종류 수 공통적인 부분과 달라지는 부분을 분리해서 재사용성을 높이고 만들어지는 클래스의 수를 줄여보자 어떻게?

Bridge - 해결 장식 효과 절차는 사진 파일 종류에 무관하게 공통 사진 파일 다루는 구체적인 방법은 각각 다르다 사진 파일 다루기를 abstract class 로 구현하자 단위 작업을 abstract method 로 이 abstract class를 상속하여 사진 파일 마다 조작 클래스를 구현한다

Bridge - 구조 사진 파일 조작 구현 클래스

Bridge - 해결 말 풍선 넣기와 같은 장식 효과 클래스는 직접 사진 파일을 다루지 않고 사진 파일 조작 구현 클래스를 사용한다 장식 효과 클래스는 PicImp 클래스와 그 메소드만 참조하여 구현될 수 있다 polymorphism 장식 효과 클래스와 연결된 사진 파일 조작 구현 클래스가 무엇이냐에 따라 jpg, gif, bmp 파일에 장식 효과가 저장된다

Bridge - 구조 + Open () Save DrawLine DrawText DrawEllipse PicImp JpegImp GifImp BmpImp Apply PhotoEffect

Bridge - 해결 PhotoEffect 의 메소드는 PicImp 의 메소드를 호출하여 구현된다 장식 효과 클래스들은 PhotoEffect 클래스의 메소드와 PicImp 클래스의 메소드를 사용하여 구현된다 장식 효과는 사진 파일 세부 사항과 무관하게 구현된다

Bridge - 구조 + Open () Save DrawLine DrawText DrawEllipse PicImp JpegImp GifImp BmpImp Apply PhotoEffect BorderEffect BallonEffect

Bridge - 결과 사진 파일에 장식 효과 주기 왼쪽의 장식 효과 객체 하나와 오늘쪽의 사진 조작 구현 객체 중 하나를 선택하여 두 객체를 결합하면 원하는 형식의 사진 파일에 원하는 장식 효과를 줄 수 있다 구현할 클래스의 수 = 장식 효과 종류의 수 + 사진 파일의 종류 수

Bridge - 결과 지원할 사진 파일의 종류가 추가될 때 사진 파일 조작 클래스 하나만 추가하면 된다 장식 효과를 추가할 때 장식 효과 클래스 하나만 추가하면 된다 장식 효과는 사진 파일 세부 사항과 무관하게 쉽게 구현될 수 있다 사진 조작 구현 클래스는 재사용성이 높다

Bridge 패턴 Bridge high level operation 과 low level operation 을 분리하여 구현하고 위임으로 연결하여 사용  bridge pattern Bridge

Bridge - Participants Implementor Abstraction RefinedAbstraction ConcreteImplementor

Decorator

Decorator - 의도 객체에 기능을 동적으로 추가할 수 있도록 하려면? 그래픽 에디터에서 사각형에 그림자를 그릴 수도 있고 선과 연결하기 위한 연결점을 붙일 수도 있으려면? 선택되었음을 뜻하는 핸들을 그릴 수 있으려면? 사각형뿐만 아니라 원, 선, 텍스트에도 위와 같은 기능을 추가할 수 있으려면?

Decorator - 의도 위 기능들을 사각형 클래스에 모두 구현하는 것은? 사각형 뿐만 아니라 다른 도형 클래스에도 모두 구현하여야 한다 즉 모든 도형에 그림자 기능을 다 구현해야 하므로 코드의 중복

Decorator - 의도 코드의 중복을 피하려면 각 클래스에 반복해서 그림자 기능을 구현하지 않고 그림자를 별도의 클래스로 분리해서 구현하는 것이 좋다 사각형 클래스와 그림자 클래스가 있을 때 두 클래스를 상속 받아 그림자가 있는 사각형 클래스를 만드는 것은? 너무 많은 서브클래스가 만들어진다 다중 상속을 지원하지 않는 언어도 있다

Decorator - 구조

Decorator - 구조

Decorator - 해결 그림자, 연결점, 핸들을 별도의 클래스로 분리해서 구현한다 장식 객체 필요에 따라 도형 객체와 장식 객체를 결합하여 사용한다 위임(delegation)

Decorator - 해결 그래픽 에디터의 명령을 장식 객체가 받아서 먼저 처리하고 도형 객체에 전달한다 즉 그래픽 에디터가 그리라는 명령을 보내면 장식 객체의 Draw() 메소드가 먼저 호출되어 장식 객체를 그리고 도형 객체의 Draw() 메소드가 호출되어 도형 객체를 그린다 결국 장식 객체와 도형 객체 둘 다 그려진다

Decorator - 해결 장식 객체는 Draw() 메소드 뿐만 아니라 Figure의 모든 메소드를 구현해야 한다 예를 들어 그래픽 에디터가 이동 명령을 보내면 장식 객체의 Move() 메소드가 먼저 호출되어 장식 객체가 이동하고 도형 객체의 Move() 메소드가 호출되어 도형 객체가 이동한다 결국 장식 객체와 도형 객체 둘 다 이동한다

Decorator - 구조

Decorator - 결과 decorator 를 여러개 결합하여 사용할 수 있다 예: ShadowDecorator  HandleDecorator  Line decorator 기능과 무관하게 도형이 추가될 수 있다 도형과 무관하게 decorator 가 추가될 수 있다 그래픽 에디터 코드는 decorator와 무관하게 구현될 수 있다

Template Method

Template Method - 의도 전체 절차는 언제나 같다 몇몇 세부 작업은 그때 그때 다르다 예: Windows 어플리케이션의 파일 열기 절차

Template Method - 의도 예: Windows 어플리케이션의 파일 열기 절차: 메뉴  File  Open  대화상자  파일선택  문서객체 생성  파일 읽기  화면에 문서 내용 표시하기 위 전체 절차는 언제나 같다 다음 세부 작업은 그때 그때 다르다 문서 객체 생성 파일 읽기 화면에 문서 내용 표시하기

Template Method - 의도 공통적인 부분과 그때 그때 다른 부분을 잘 분리하여 공통적인 부분의 재사용성을 향상시키고 최소한의 코딩으로 그때 그때 다른 부분을 구현할 수 있으려면? 공통적인 전체 절차와 그때 그때 다른 단위 스텝

Template Method - 해결 abstract class 를 만든다 전체 절차에 해당하는 메소드를 만든다 공통적인 부분 단위 스텝에 해당하는 메소드를 호출하는 형태로 구현된다 concrete method 로 구현할 수 있다 단위 스텝에 해당하는 메소드를 만든다 세부 작업 내용이 공통적이라면 concrete method 로 구현 세부 작업 내용이 그때 그때 달라져야 한다면 abstract method 로 선언한다

Template Method - 해결 메뉴  File  Open  대화상자  파일선택  문서객체 생성  파일 읽기  화면에 문서 내용 표시하기 공통적인 단위 스텝 메뉴  File  Open 대화상자 파일선택 매번 달라져야하는 단위 스텝 문서객체 생성 파일 읽기 화면에 문서 내용 표시하기

Template Method - 해결 역할별로 분리하여 클래스를 만든다 Application View Document

Template Method - 해결 Application 클래스의 역할 메뉴  File  Open 대화상자 파일선택 문서 객체 생성 Document 클래스의 역할 파일 읽기 View 클래스의 역할 화면에 문서 내용 표시하기

Template Method - 구조 void Application::OnFileOpen() { + Open ( in fileName : string ) Document OnFileOpen () ShowFileOpenDlg () : CreateDocument Application DrawDocument View void Application::OnFileOpen() { string fname = ShowFileOpenDlg(); Document doc = CreateDocument(); doc.Open(fname); view.DrawDocument(); }

Template Method - 구조 공통적인 전체 절차  Application.OnFileNew() 메소드로 구현 공통적인 단위스텝 Application.ShowFileOpenDlg() 구현 매번 달라지는 단위스텝  abstract method 로 선언 Application.CreateDocument() Document.Open() Document.DrawDocument()

Template Method - 구조 void MyApplication::CreateDocument () { + Open ( in fileName : string ) Document OnFileOpen () ShowFileOpenDlg () : CreateDocument Application MyDocument MyApplication DrawDocument View MyView void MyApplication::CreateDocument () { return new MyDocument(); }

Template Method - 구조 어플리케이션을 개발할 때는 abstract class를 상속 받아서 구현 concrete method 매번 달라지는 단위스텝은 abstract method 를 재정의 한다 하위 클래스는 반드스 abstract method 를 재정의 하여야 한다 공통적인 부분과 매번 달라지는 부분의 분리 재사용성이 높은 abstract class CreateDocument() 메소드가 template method 이다