JavaScript 디자인에서 Facade 모드와 Mediator 모드의 차이점에 대한 자세한 예

Facade 모드는 이 기사의 아키텍처에서 중요한 역할을 합니다. 이 모드는 많은 JavaScript 라이브러리 또는 프레임워크에 반영됩니다. 즉, 특정 구현을 숨기기 위해 상위 수준 API를 포함하는 것입니다. 내부 구현은 우리가 직접 결정할 수 있습니다. 이는 내부 구현 코드를 쉽게 수정하고 업데이트할 수 있음을 의미합니다. 예를 들어, 오늘 jQuery를 사용하여 구현하고 내일 YUI로 변경하려는 경우 이는 매우 중요합니다. 편리한. .

다음 예에서는 많은 비공개 메소드를 제공한 다음 외부 세계에서 내부 메소드를 실행하고 호출할 수 있도록 간단한 API를 노출하는 것을 보여줍니다.

var module = (function () {
 var _private = {
 i: 5,
 get: function () {
  console.log('current value:' + this.i);
 },
 set: function (val) {
  this.i = val;
 },
 run: function () {
  console.log('running');
 },
 jump: function () {
  console.log('jumping');
 }
 };
 return {
 facade: function (args) {
  _private.set(args.val);
  _private.get();
  if (args.run) {
  _private.run();
  }
 }
 }
} ());

module.facade({run:true, val:10});
//outputs current value: 10, running

Facade와 아래에서 중재자라고 부르는 차이점 Facade는 기존 기능만 제공하는 반면 중재자는 새로운 기능을 추가할 수 있다는 것입니다.

메디에이터 모드

메디에이터에 대해 이야기하기 전에, 전설적인 타워라고도 알려진 공항 비행 관제 시스템은 모든 항공기의 이착륙 시간과 장소를 통제할 수 있습니다. 이전에는 항공기와 항공기의 통신이 허용되지 않았는데, 이는 타워가 공항의 핵심이고 중재자가 이 타워와 동일하다는 것을 의미합니다.

Mediator는 프로그램에 여러 모듈이 있고 각 모듈이 종속성을 갖는 것을 원하지 않을 때 사용됩니다. 그러면 mediator 모드를 통해 중앙 집중식 제어의 목적을 달성할 수 있습니다. 실제 시나리오에서도 중재자는 원하지 않는 많은 모듈을 캡슐화하여 중재자를 통해 연결되도록 허용하는 동시에 느슨하게 결합하므로 중재자를 통해 통신해야 합니다.

조정자 모드의 장점은 무엇인가요? 그것이 디커플링입니다. 이전에 관찰자 패턴을 잘 이해했다면 아래 그림은 고급 중재자 패턴 다이어그램을 이해하는 것이 비교적 간단합니다.

각 모듈을 생각해 보세요. 게시자이고 중재자는 게시자이자 구독자입니다.

모듈 1은 조치가 필요하다는 사실을 Mediator에 브로드캐스트합니다.
Mediator는 메시지를 캡처한 후 즉시 메시지 처리에 사용해야 하는 모듈 2를 시작하고, 모듈 2는 처리를 완료한 후 정보를 Mediator에 반환합니다.
동시에 중재자는 모듈 3을 시작하고, 모듈 2에서 반환된 메시지를 받으면 자동으로 모듈 3에 로그를 기록합니다. 보시다시피 모듈 간에 통신이 없습니다. 또한 중재자는 구현할 수도 있습니다. 각 모듈의 상태를 모니터링하는 기능, 예를 들어 모듈 3이 잘못되면 Mediator는 일시적으로 다른 모듈만 생각한 후 모듈 3을 다시 시작한 다음 실행을 계속할 수 있습니다.

돌이켜 보면 Mediator의 장점은 느슨하게 연결된 모듈이 동일한 Mediator에 의해 제어된다는 것입니다. 모듈은 이벤트를 브로드캐스팅하고 수신하기만 하면 되며 모듈 간에 직접 접촉이 필요하지 않습니다. 정보가 처리되면 여러 모듈을 사용하여 처리할 수 있으며, 이는 향후 기존 제어 로직에 새 모듈을 균일하게 추가하는 것도 용이하게 합니다.

확실히: 모든 모듈이 직접 통신을 할 수 없기 때문에 상대적으로 성능이 조금 저하될 수는 있지만 그만한 가치가 있다고 생각합니다.

위 설명을 바탕으로 간단한 데모를 만들겠습니다.

var mediator = (function(){
 var subscribe = function(channel, fn){
 if (!mediator.channels[channel]) mediator.channels[channel] = [];
 mediator.channels[channel].push({ context: this, callback: fn });
 return this;
 },
 
 publish = function(channel){
 if (!mediator.channels[channel]) return false;
 var args = Array.prototype.slice.call(arguments, 1);
 for (var i = 0, l = mediator.channels[channel].length; i < l; i++) {
  var subscription = mediator.channels[channel][i];
  subscription.callback.apply(subscription.context, args);
 }
 return this;
 };
 
 return {
 channels: {},
 publish: publish,
 subscribe: subscribe,
 installTo: function(obj){
  obj.subscribe = subscribe;
  obj.publish = publish;
 }
 };
 
}());

그러면 각각 호출되는 2개의 모듈이 있습니다.

//Pub/sub on a centralized mediator
 
mediator.name = "tim";
mediator.subscribe('nameChange', function(arg){
 console.log(this.name);
 this.name = arg;
 console.log(this.name);
});
 
mediator.publish('nameChange', 'david'); //tim, david
 
 
//Pub/sub via third party mediator
 
var obj = { name: 'sam' };
mediator.installTo(obj);
obj.subscribe('nameChange', function(arg){
 console.log(this.name);
 this.name = arg;
 console.log(this.name);
});
 
obj.publish('nameChange', 'john'); //sam, john

Application Facade: 애플리케이션 핵심 추상화

파사드는 애플리케이션 코어의 추상화 역할을 하며 중재자와 모듈 간의 통신을 담당합니다. 각 모듈은 이 파사드를 통해서만 프로그램 코어와 통신할 수 있습니다. 추상화로서, 센드박스 컨트롤러의 역할과 유사하게 이러한 모듈에 대해 항상 일관된 인터페이스(일관된 인터페이스)가 제공될 수 있도록 보장하는 것이 책임입니다. 모든 모듈 구성 요소는 이를 통해 중재자와 통신하므로 Facade는 신뢰할 수 있고 신뢰할 수 있어야 함과 동시에 모듈에 대한 인터페이스를 제공하는 기능으로 보안 제어라는 또 다른 역할도 수행해야 합니다. 즉, 모듈에서 액세스할 수 있는 프로그램 부분을 결정합니다. 모듈 구성 요소는 자체 메서드만 호출할 수 있으며 승인되지 않은 콘텐츠에는 액세스할 수 없습니다. 예를 들어, 모듈은 dataValidationCompletedWriteToDB를 브로드캐스트할 수 있으며 여기서 보안 검사는 모듈에 데이터베이스에 대한 쓰기 권한이 있는지 확인해야 합니다.

간단히 말하면 중재자는 외관 승인 감지 이후에만 정보를 처리할 수 있습니다.

Application Mediator: 애플리케이션의 핵심

Mediator는 애플리케이션의 핵심 역할을 담당합니다. 핵심 작업은 모듈의 수명 주기를 관리하는 것입니다. 이 코어는 들어오는 정보를 캡처할 때 프로그램이 이를 처리하는 방법, 즉 시작하거나 중지할 모듈을 결정해야 합니다. 모듈이 시작되면 애플리케이션 코어가 실행 여부(예: DOM이 준비되었을 때 실행해야 하는지 여부)를 결정하지 않고도 자동으로 실행될 수 있어야 하므로 모듈 자체에서 결정을 내려야 합니다.

어떤 상황에서 모듈이 중지되는지에 대한 질문이 여전히 있을 수 있습니다. 프로그램이 모듈이 실패했거나 오류가 발생했음을 감지하면 구성 요소를 다시 시작할 수 있도록 모듈의 메서드가 계속 실행되지 않도록 결정을 내려야 합니다. 주요 목적은 사용자를 개선하는 것입니다. 경험.

또한 코어는 다른 기능에 영향을 주지 않고 동적으로 모듈을 추가하거나 삭제할 수 있어야 합니다. 일반적인 예로는 페이지 로딩 초기에는 모듈을 사용할 수 없지만, 사용자 작업 후에는 Gmail의 채팅 기능과 마찬가지로 모듈을 동적으로 로딩하고 실행해야 하는 경우가 성능 최적화 측면에서 필요합니다. 아주 좋아. 이해해.

예외 오류 처리도 애플리케이션 코어에서 처리됩니다. 또한 각 모듈이 정보를 브로드캐스트할 때 모든 오류를 코어에 브로드캐스트하므로 프로그램 코어는 상황에 따라 이러한 모듈을 중지/다시 시작할 수 있습니다. 이는 느슨하게 결합된 아키텍처의 중요한 부분이기도 합니다. 중재자를 통해 게시/구독을 사용하면 모듈을 수동으로 변경할 필요가 없습니다.

위 내용은 JavaScript 디자인에서 Facade 모드와 Mediator 모드의 차이점에 대한 자세한 예의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!