중재자 패턴

Mediator pattern

소프트웨어 엔지니어링에서 중재자 패턴은 객체 집합이 상호작용하는 방법을 캡슐화하는 객체를 정의한다.이 패턴은 프로그램의 실행 행동을 변화시킬 수 있는 방법 때문에 행동 패턴으로 간주된다.

객체 지향 프로그래밍에서 프로그램은 많은 클래스로 구성되는 경우가 많다.비즈니스 논리연산은 이 세분류에 분포한다.그러나 특히 유지관리 및/또는 리팩터링 중에 프로그램에 더 많은 클래스가 추가됨에 따라 이러한 클래스 간의 통신 문제가 더욱 복잡해질 수 있다.이것은 프로그램을 읽고 유지하기 어렵게 만든다.게다가, 어떤 변화가 다른 몇몇 수업의 코드에 영향을 미칠 수 있기 때문에 프로그램을 바꾸는 것은 어려워질 수 있다.

중재자 패턴으로 개체 간의 통신이 중재자 객체 내에 캡슐화된다.물체는 더 이상 서로 직접 소통하지 않고 중재자를 통해 소통한다.이것은 통신하는 물체들 사이의 의존성을 감소시켜 결합을 감소시킨다.

개요

중재자[1] 설계 패턴은 유연하고 재사용 가능한 객체 지향 소프트웨어, 즉 구현, 변경, 테스트 및 재사용하기 쉬운 객체를 설계하기 위해 반복되는 설계 문제를 해결하는 방법을 설명하는 23가지 잘 알려진 설계 패턴 중 하나이다.

중재자 설계 패턴이 해결할 수 있는 문제는 무엇인가?[2]

  • 상호 작용하는 물체들 사이의 결합은 피해야 한다.
  • 개체 집합 간의 상호작용을 독립적으로 변경할 수 있어야 한다.

상호작용을 하는 객체들의 집합에 직접 접근하고 업데이트함으로써 상호작용을 정의하는 것은, 상호작용을 서로 밀접하게 결합시키고, 객체로부터 (변경하지 않고) 독립적으로 변경할 수 없게 하기 때문에 융통성이 없다.그리고 그것은 그 물체들이 재사용되는 것을 막고 그것들을 시험하기 어렵게 만든다.

촘촘히 결합한 물체는 서로 다른 많은 물체를 참조하고 알기 때문에 구현, 변경, 테스트 및 재사용하기가 어렵다.

중재자 설계 패턴은 어떤 해결책을 설명하고 있는가?

  • 개체 집합 간의 상호 작용을 캡슐화하는 별도의(중재기) 개체를 정의하십시오.
  • 개체는 서로 직접 상호작용하는 대신 중재자 대상에게 상호작용을 위임한다.

물체는 상호작용을 제어하고 조정하는 중재자 물체를 통해 간접적으로 상호작용을 한다.

이것은 물체들을 느슨하게 결합하게 만든다.그들은 중재자 대상만을 언급하고 알 뿐 서로에 대한 명시적인 지식은 없다.

아래 UML 클래스 및 시퀀스 다이어그램을 참조하십시오.

정의

중재자 패턴의 본질은 "물체 집합이 상호작용하는 방법을 캡슐화하는 물체를 정의"하는 것이다.물체가 서로 명시적으로 언급되지 않도록 함으로써 느슨한 결합을 촉진하고, 물체의 상호작용을 독립적으로 변화시킬 수 있도록 한다.[3][4]클라이언트 클래스는 중재자를 사용하여 다른 클라이언트에 메시지를 보낼 수 있으며 중재자 클래스의 이벤트를 통해 다른 클라이언트로부터 메시지를 받을 수 있다.

구조

UML 클래스 및 시퀀스 다이어그램

중재자 설계 패턴에 대한 샘플 UML 클래스 및 시퀀스 다이어그램.[5]

위의 UML클래스 다이어그램에서Colleague1그리고Colleague2클래스는 서로 직접 참조(및 업데이트)하지 않는다.대신 그들은 공통점을 가리킨다.Mediator상호 작용 제어 및 조정을 위한 인터페이스(mediate()() 따라서 상호 작용이 어떻게 수행되는지와 관련하여 서로 독립적으로 된다.Mediator1클래스 간의 상호 작용 구현Colleague1그리고Colleague2.

UMLsequence 다이어그램은 런타임 상호작용을 보여준다.이 예에서 aMediator1물체는 사이의 상호작용을 매개(상호 및 좌표)한다.Colleague1그리고Colleague2물건들

라고 가정하면Colleague1교감하고 싶어하다Colleague2(예를 들어 상태를 업데이트/수정하려면)Colleague1전화를 하다mediate(this)에서Mediator1객체: 변경된 데이터를 가져오는 객체Colleague1그리고 공연을 한다.action2()에 관하여Colleague2.

그 후,Colleague2전화를 하다mediate(this)에서Mediator1객체: 변경된 데이터를 가져오는 객체Colleague2그리고 공연을 한다.action1()에 관하여Colleague1.

클래스 다이어그램

중재자 행동 설계 패턴
참가자

중재자 - 동료 개체 간의 통신을 위한 인터페이스 정의

ConcreteMediator - 중재자 인터페이스를 구현하고 동료 객체 간의 통신을 조정한다.그것은 상호소통에 관한 모든 동료들과 그들의 목적을 알고 있다.

동료 - 중재자를 통해 다른 동료와 커뮤니케이션할 수 있는 인터페이스 정의

ConcreteColleg - 동료 인터페이스 구현 및 중재자를 통해 다른 동료와 통신

C#

중재자 패턴은 구성 요소가 서로 명시적으로 전화하지 않고 중재자에 대한 호출을 통해 느슨하게 결합되도록 보장한다.다음 예에서 중재자는 모든 구성요소를 등록한 후 SetState 메서드를 호출한다.

접점 ICOMPER {     공허하게 하다 SetState(이의를 제기하다 ); }  계급 성분1 : ICOMPER {     내부의 공허하게 하다 SetState(이의를 제기하다 )     {         던지다 새로운 구현되지 않음예외();     } }  계급 성분2 : ICOMPER {     내부의 공허하게 하다 SetState(이의를 제기하다 )     {         던지다 새로운 구현되지 않음예외();     } }  // 공통 작업 조정 계급 중재자 {     내부의 ICOMPER 성분1 { 얻다; 세트; }     내부의 ICOMPER 성분2 { 얻다; 세트; }      내부의 공허하게 하다 ChangeState(이의를 제기하다 )     {         .성분1.SetState();         .성분2.SetState();     } } 

채팅 룸은 중재자 패턴 또는 다른 클라이언트 중 한 명이 액션을 수행할 때마다 많은 '고객'이 각각 메시지를 수신하는 시스템을 사용할 수 있다(대화 룸의 경우, 각 사용자가 메시지를 보낼 때 해당).현실적으로 대화방에 중재자 패턴을 사용하는 것은 원격으로 사용할 때만 실용적일 것이다.원시 소켓을 사용하면 대리자 콜백(중재자 클래스의 Message Received 이벤트에 가입한 사용자)이 허용되지 않는다.

공중의 위임하다 공허하게 하다 Message ReceivedEventHandler(끈을 매다 메세지, 끈을 매다 발송인);  공중의 계급 중재자 {     공중의 사건 Message ReceivedEventHandler 받은 메시지;      공중의 공허하게 하다 보내다(끈을 매다 메세지, 끈을 매다 발송인)     {         만일 (받은 메시지 != 무효의)         {             콘솔.WriteLine("{0}'을(를) {1}에서 보내는 중", 메세지, 발송인);             받은 메시지(메세지, 발송인);         }     } }  공중의 계급 사람 {     사유의 중재자 _beakes;      공중의 끈을 매다 이름 { 얻다; 세트; }      공중의 사람(중재자 중재자, 끈을 매다 이름을 붙이다)     {         이름 = 이름을 붙이다;         _beakes = 중재자;         _beakes.받은 메시지 += 새로운 Message ReceivedEventHandler(받다);     }      사유의 공허하게 하다 받다(끈을 매다 메세지, 끈을 매다 발송인)     {         만일 (발송인 != 이름)             콘솔.WriteLine("{0}가 {2}에서 '{1}'을(를) 수신함", 이름, 메세지, 발송인);     }      공중의 공허하게 하다 보내다(끈을 매다 메세지)     {         _beakes.보내다(메세지, 이름);     } } 

자바

다음 예에서 aMediator개체는 여러 개의 값을 제어한다.Storage개체, 사용자 코드가 중재자를 통해 저장된 값에 액세스하도록 강제하는 경우.저장 객체가 해당 값이 변경되었음을 나타내는 이벤트를 내보내고자 할 때는 (방법을 통해) 중재자 객체로 돌아가기도 한다.notifyObservers관찰자 목록(관찰자 패턴 사용)을 제어하는 기능.

수입하다 java.util.해시맵; 수입하다 java.util.선택적; 수입하다 java.util.property.dlls.CopyOnWriteArrayList; 수입하다 java.util.function.소비자;  계급 저장<T> {     T 가치를 매기다;          T getValue() {         돌아오다 가치를 매기다;     }     공허하게 하다 setValue(중재자<T> 중재자,  저장소 이름, T 가치를 매기다) {         .가치를 매기다 = 가치를 매기다;         중재자.notifyObservers(저장소 이름);     } }  계급 중재자<T> {     사유의 최종의 해시맵<, 저장<T>> 저장소맵 = 새로운 해시맵<>();     사유의 최종의 CopyOnWriteArrayList<소비자<>> 감시자들 = 새로운 CopyOnWriteArrayList<>();          공중의 공허하게 하다 setValue( 저장소 이름, T 가치를 매기다) {         저장 창고 = 저장소맵.computeIfAbsent(저장소 이름, 이름을 붙이다 -> 새로운 저장<>());         창고.setValue(, 저장소 이름, 가치를 매기다);     }          공중의 선택적<T> getValue( 저장소 이름) {         돌아오다 선택적.불가해한(저장소맵.얻다(저장소 이름)).지도를 그리다(저장::getValue);     }          공중의 공허하게 하다 addObserver( 저장소 이름, 런너블 관찰자) {         감시자들.덧셈을(eventName -> {             만일 (eventName.대등하다(저장소 이름)) {                 관찰자.달리다();             }         });     }          공허하게 하다 notifyObservers( eventName) {         감시자들.각을 위해(관찰자 -> 관찰자.받아들이다(eventName));     } }  공중의 계급 중재자데모 {     공중의 정태의 공허하게 하다 본래의([] 아그) {         중재자<정수> 중재자 = 새로운 중재자<>();         중재자.setValue("bob", 20);         중재자.setValue("alice", 24);         중재자.getValue("alice").if현재(나이를 먹다 -> 시스템.밖으로.인쇄하다("앨리스의 나이:" + 나이를 먹다));                  중재자.addObserver("bob", () -> {             시스템.밖으로.인쇄하다("밥의 새로운 나이:" + 중재자.getValue("bob").오렐스 던지기(RuntimeException::새로운));         });         중재자.setValue("bob", 21);     } } 

참고 항목

참조

  1. ^ Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides (1994). Design Patterns: Elements of Reusable Object-Oriented Software. Addison Wesley. pp. 273ff. ISBN 0-201-63361-2.{{cite book}}: CS1 maint : 복수이름 : 작성자 목록(링크)
  2. ^ Franke, Günther. "The Mediator design pattern - Problem, Solution, and Applicability". w3sDesign. Retrieved 2017-08-12.
  3. ^ Gamma, Erich; Helm, Richard; Johnson, Ralph; Vlissides, John (1994). Design Patterns. Addison-Wesley. ISBN 0-201-63361-2.
  4. ^ "Mediator Design Pattern". SourceMaking.
  5. ^ Franke, Günther. "The Mediator design pattern - Structure and Collaboration". w3sDesign. Retrieved 2017-08-12.

외부 링크