Yayınlama / Abone Olma modeli (JS / jQuery'de) neden kullanılır?

Yani, bir meslektaşım (JS / jQuery) Yayın / abonelik desen beni tanıştırdı ama kulpları ile almak zor bir zaman yaşıyorum neden kimse 'normal' JavaScript / jQuery üzerinde bu kalıbı kullanmak.

Örneğin, daha önce şu koda sahiptim ...

$container.on('click', '.remove_order', function(event) {
    event.preventDefault();
    var orders = $(this).parents('form:first').find('div.order');
    if (orders.length > 2) {
        orders.last().remove();
    }
});

Ve bunun yerine bunu yapmanın değerini görebiliyordum, örneğin ...

removeOrder = function(orders) {
    if (orders.length > 2) {
        orders.last().remove();
    }
}

$container.on('click', '.remove_order', function(event) {
    event.preventDefault();
    removeOrder($(this).parents('form:first').find('div.order'));
});

Çünkü removeOrderfarklı olaylar vb. İçin işlevselliği yeniden kullanma yeteneği sunar .

Peki aynı şeyi yapıyorsa neden yayınlama / abone olma modelini uygulamaya ve aşağıdaki uzunluklara gitmeye karar verdiniz? (Bilginize, jQuery küçük pub / alt kullandım )

removeOrder = function(e, orders) {
    if (orders.length > 2) {
        orders.last().remove();
    }
}

$.subscribe('iquery/action/remove-order', removeOrder);

$container.on('click', '.remove_order', function(event) {
    event.preventDefault();
    $.publish('iquery/action/remove-order', $(this).parents('form:first').find('div.order'));
});

Örüntü hakkında kesin olarak okudum, ancak bunun neden gerekli olduğunu hayal edemiyorum. Bu kalıbın nasıl uygulanacağını açıklayan gördüğüm öğreticiler, sadece benimki kadar temel örnekleri kapsıyor.

Pub / sub'ın kullanışlılığının daha karmaşık bir uygulamada kendini göstereceğini hayal ediyorum, ancak bir tane hayal edemiyorum. Korkarım noktayı tamamen kaçırıyorum; ama eğer varsa bir noktayı bilmek isterim!

Bu modelin neden ve hangi durumlarda avantajlı olduğunu kısaca açıklayabilir misiniz ? Yukarıdaki örneklerim gibi kod parçacıkları için pub / sub modelini kullanmaya değer mi?

Her şey, son birkaç yılda çok modern olan JavaScript'teki MV * (MVC / MVP / MVVM) kalıplarıyla el ele giden gevşek bağlantı ve tek sorumlulukla ilgili.

Gevşek bağlantı , sistemin her bir bileşeninin kendi sorumluluğunu bildiği ve diğer bileşenleri umursamadığı (veya en azından bunları mümkün olduğunca önemsememeye çalıştığı) Nesne odaklı bir ilkedir. Gevşek bağlantı iyi bir şeydir çünkü farklı modülleri kolayca yeniden kullanabilirsiniz. Diğer modüllerin arayüzlerine bağlı değilsiniz. Yayınlama / abone olma özelliğini kullanarak yalnızca yayınlama / abone olma arayüzüne bağlanırsınız ki bu çok da önemli değildir - sadece iki yöntem. Dolayısıyla, bir modülü farklı bir projede yeniden kullanmaya karar verirseniz, onu kopyalayıp yapıştırabilirsiniz ve muhtemelen işe yarayacaktır ya da en azından çalışması için fazla çabaya ihtiyacınız olmayacaktır.

Gevşek bağlantıdan bahsederken endişelerin ayrılığından bahsetmeliyiz. Bir MV * mimari modeli kullanarak bir uygulama oluşturuyorsanız, her zaman bir Modeliniz ve bir Görünümünüz vardır. Model, uygulamanın iş bölümüdür. Bunu farklı uygulamalarda yeniden kullanabilirsiniz, bu nedenle onu göstermek istediğiniz yerde tek bir uygulamanın Görünümü ile birleştirmek iyi bir fikir değildir, çünkü genellikle farklı uygulamalarda farklı görünümlere sahip olursunuz. Bu nedenle Model-Görünüm iletişimi için yayınlama / abone olma yöntemini kullanmak iyi bir fikirdir. Modeliniz değiştiğinde bir olay yayınlar, Görünüm onu ​​yakalar ve kendini günceller. Yayınlama / abone olmanın herhangi bir ek yüküne sahip değilsiniz, bu ayrıştırma için size yardımcı oluyor. Aynı şekilde, uygulama mantığınızı Denetleyicide tutabilirsiniz, örneğin (MVVM, MVP tam olarak bir Denetleyici değildir) ve Görünümü olabildiğince basit tutabilirsiniz. Görünümünüz değiştiğinde (veya kullanıcı bir şeye tıkladığında) sadece yeni bir olay yayınlar, Kontrolör onu yakalar ve ne yapacağına karar verir. Aşina isenizMVC kalıbı veya Microsoft teknolojilerinde (WPF / Silverlight) MVVM ile Gözlemci kalıbı gibi yayınlama / abonelik düşünebilirsiniz . Bu yaklaşım, Backbone.js, Knockout.js (MVVM) gibi çerçevelerde kullanılır.

İşte bir örnek:

//Model
function Book(name, isbn) {
    this.name = name;
    this.isbn = isbn;
}

function BookCollection(books) {
    this.books = books;
}

BookCollection.prototype.addBook = function (book) {
    this.books.push(book);
    $.publish('book-added', book);
    return book;
}

BookCollection.prototype.removeBook = function (book) {
   var removed;
   if (typeof book === 'number') {
       removed = this.books.splice(book, 1);
   }
   for (var i = 0; i < this.books.length; i += 1) {
      if (this.books[i] === book) {
          removed = this.books.splice(i, 1);
      }
   }
   $.publish('book-removed', removed);
   return removed;
}

//View
var BookListView = (function () {

   function removeBook(book) {
      $('#' + book.isbn).remove();
   }

   function addBook(book) {
      $('#bookList').append('<div id="' + book.isbn + '">' + book.name + '</div>');
   }

   return {
      init: function () {
         $.subscribe('book-removed', removeBook);
         $.subscribe('book-aded', addBook);
      }
   }
}());

Başka bir örnek. MV * yaklaşımından hoşlanmıyorsanız, biraz farklı bir şey kullanabilirsiniz (bir sonraki tarif edeceğim ve son bahsedilen arasında bir kesişme var). Uygulamanızı farklı modüllerde yapılandırmanız yeterlidir. Örneğin Twitter'a bakın.

Arayüze bakarsanız, farklı kutulara sahipsiniz. Her kutuyu farklı bir modül olarak düşünebilirsiniz. Örneğin bir tweet atabilirsiniz. Bu eylem birkaç modülün güncellenmesini gerektirir. Öncelikle profil verilerinizi güncellemeli (sol üst kutu), ancak aynı zamanda zaman çizelgenizi de güncellemelidir. Elbette, her iki modüle ilişkin referansları tutabilir ve genel arayüzlerini kullanarak bunları ayrı ayrı güncelleyebilirsiniz, ancak yalnızca bir etkinliği yayınlamak daha kolay (ve daha iyi). Bu, daha gevşek bağlantı nedeniyle uygulamanızın değiştirilmesini kolaylaştıracaktır. Yeni tweetlere bağlı yeni bir modül geliştirirseniz, sadece “tweet yayınla” etkinliğine abone olabilir ve onu halledebilirsiniz. Bu yaklaşım çok kullanışlıdır ve uygulamanızı oldukça ayrıştırabilir. Modüllerinizi çok kolay bir şekilde yeniden kullanabilirsiniz.

İşte son yaklaşımın temel bir örneği (bu orijinal twitter kodu değil, sadece benim tarafımdan bir örnek):

var Twitter.Timeline = (function () {
   var tweets = [];
   function publishTweet(tweet) {
      tweets.push(tweet);
      //publishing the tweet
   };
   return {
      init: function () {
         $.subscribe('tweet-posted', function (data) {
             publishTweet(data);
         });
      }
   };
}());


var Twitter.TweetPoster = (function () {
   return {
       init: function () {
           $('#postTweet').bind('click', function () {
               var tweet = $('#tweetInput').val();
               $.publish('tweet-posted', tweet);
           });
       }
   };
}());

Bu yaklaşım için Nicholas Zakas'ın harika bir konuşması var . MV * yaklaşımı için bildiğim en iyi makaleler ve kitaplar Addy Osmani tarafından yayınlandı .

Dezavantajlar: Aşırı yayınlama / abone olma konusunda dikkatli olmalısınız. Yüzlerce etkinliğiniz varsa, hepsini yönetmek çok kafa karıştırıcı olabilir. Ad alanı kullanmıyorsanız (veya doğru şekilde kullanmıyorsanız) da çarpışmalar yaşayabilirsiniz. Bir yayınlama / abone olma gibi görünen gelişmiş bir Mediator uygulaması https://github.com/ajacksified/Mediator.js adresinde bulunabilir . Ad alanı ve tabii ki kesintiye uğratılabilen olay “köpürme” gibi özelliklere sahiptir. Yayınlamanın / abone olmanın bir başka dezavantajı, katı birim testidir, modüllerdeki farklı işlevleri izole etmek ve bunları bağımsız olarak test etmek zor olabilir.

Ana amaç, kod arasındaki bağlantıyı azaltmaktır. Bu biraz olay temelli bir düşünme biçimidir, ancak "olaylar" belirli bir nesneye bağlı değildir.

Aşağıda JavaScript'e biraz benzeyen bazı sözde kodlarda büyük bir örnek yazacağım.

Diyelim ki bir sınıf Radyomuz ve bir sınıf Relayimiz var:

class Relay {
    function RelaySignal(signal) {
        //do something we don't care about right now
    }
}

class Radio {
    function ReceiveSignal(signal) {
        //how do I send this signal to other relays?
    }
}

Radyo bir sinyal aldığında, mesajı bir şekilde iletmek için bir dizi rölenin olmasını isteriz. Röle sayısı ve türü farklılık gösterebilir. Bunu şu şekilde yapabiliriz:

class Radio {
    var relayList = [];

    function AddRelay(relay) {
        relayList.add(relay);
    }

    function ReceiveSignal(signal) {
        for(relay in relayList) {
            relay.Relay(signal);
        }
    }

}

Bu iyi çalışıyor. Ancak şimdi, Radio sınıfının aldığı sinyallerin, yani Speakers'ın, başka bir bileşenin de parçası olmasını istediğimizi hayal edin:

(analojiler birinci sınıf değilse özür dilerim ...)

class Speakers {
    function PlaySignal(signal) {
        //do something with the signal to create sounds
    }
}

Modeli tekrar tekrar edebiliriz:

class Radio {
    var relayList = [];
    var speakerList = [];

    function AddRelay(relay) {
        relayList.add(relay);
    }

    function AddSpeaker(speaker) {
        speakerList.add(speaker)
    }

    function ReceiveSignal(signal) {

        for(relay in relayList) {
            relay.Relay(signal);
        }

        for(speaker in speakerList) {
            speaker.PlaySignal(signal);
        }

    }

}

Bunu, "SignalListener" gibi bir arayüz oluşturarak daha da iyi hale getirebiliriz, böylece Radio sınıfında sadece bir listeye ihtiyacımız var ve sinyali dinlemek isteyen her nesneye her zaman aynı işlevi çağırabiliriz. Ancak bu yine de karar verdiğimiz arayüz / temel sınıf / vb. İle Radio sınıfı arasında bir bağlantı oluşturur. Temel olarak, Radyo, Sinyal veya Röle sınıflarından birini değiştirdiğinizde, diğer iki sınıfı nasıl etkileyebileceğini düşünmeniz gerekir.

Şimdi farklı bir şey deneyelim. RadioMast adında dördüncü bir sınıf oluşturalım:

class RadioMast {

    var receivers = [];

    //this is the "subscribe"
    function RegisterReceivers(signaltype, receiverMethod) {
        //if no list for this type of signal exits, create it
        if(receivers[signaltype] == null) {
            receivers[signaltype] = [];
        }
        //add a subscriber to this signal type
        receivers[signaltype].add(receiverMethod);
    }

    //this is the "publish"
    function Broadcast(signaltype, signal) {
        //loop through all receivers for this type of signal
        //and call them with the signal
        for(receiverMethod in receivers[signaltype]) {
            receiverMethod(signal);
        }
    }
}

Artık farkında olduğumuz bir modelimiz var ve bunu herhangi bir sayı ve türdeki sınıflar için kullanabiliriz:

• RadioMast'ın (geçen tüm mesajları işleyen sınıf) farkındadır
• mesaj gönderme / alma yöntem imzasının farkındadır

Bu yüzden Radio sınıfını nihai, basit biçimine değiştiriyoruz:

class Radio {
    function ReceiveSignal(signal) {
        RadioMast.Broadcast("specialradiosignal", signal);
    }
}

Bu tür sinyal için hoparlörleri ve röleyi RadioMast'ın alıcı listesine ekliyoruz:

RadioMast.RegisterReceivers("specialradiosignal", speakers.PlaySignal);
RadioMast.RegisterReceivers("specialradiosignal", relay.RelaySignal);

Artık Speakers ve Relay sınıfı, sinyal alabilen bir yönteme sahip olmaları dışında hiçbir şey hakkında sıfır bilgiye sahiptir ve yayıncı olan Radio sınıfı, sinyalleri yayınladığı RadioMast'ın farkındadır. Bu, yayınlama / abone olma gibi bir mesaj iletme sistemi kullanmanın amacıdır.

Diğer cevaplar, modelin nasıl çalıştığını göstermede harika bir iş çıkardı. Son zamanlarda bu model üzerinde çalıştığım için " eski yöntemde neyin yanlış? " Sorusunu ele almak istedim ve bunun düşüncemde bir değişiklik olduğunu görüyorum.

Bir ekonomi bültenine abone olduğumuzu hayal edin. Bülten bir başlık yayınlıyor: " Dow Jones'u 200 puan düşürün ". Bu, tuhaf ve bir bakıma sorumsuzca gönderilecek bir mesaj olur. Ancak, " Enron bu sabah 11. bölüm iflas koruması için başvurdu " yayınladıysa , bu daha yararlı bir mesajdır. Mesajın Dow Jones'un 200 puan düşmesine neden olabileceğini unutmayın , ancak bu başka bir konudur.

Bir komut göndermek ile yeni olmuş bir şey hakkında tavsiye vermek arasında bir fark vardır. Bunu aklınızda tutarak, işleyiciyi şimdilik görmezden gelerek, pub / sub modelinin orijinal versiyonunu alın:

$.subscribe('iquery/action/remove-order', removeOrder);

$container.on('click', '.remove_order', function(event) {
    event.preventDefault();
    $.publish('iquery/action/remove-order', $(this).parents('form:first').find('div.order'));
});

Burada, kullanıcı eylemi (bir tıklama) ve sistem yanıtı (kaldırılan bir emir) arasında zaten zımni güçlü bir bağlantı vardır. Örneğinizde etkili bir şekilde, eylem bir emir veriyor. Bu versiyonu düşünün:

$.subscribe('iquery/action/remove-order-requested', handleRemoveOrderRequest);

$container.on('click', '.remove_order', function(event) {
    event.preventDefault();
    $.publish('iquery/action/remove-order-requested', $(this).parents('form:first').find('div.order'));
});

Şimdi işleyici, meydana gelen ilginç bir şeye yanıt veriyor, ancak bir emri kaldırma yükümlülüğü altında değil. Aslında işleyici, bir siparişin kaldırılmasıyla doğrudan ilgili olmayan her türlü şeyi yapabilir, ancak yine de çağrı eylemiyle ilgili olabilir. Örneğin:

handleRemoveOrderRequest = function(e, orders) {
    logAction(e, "remove order requested");
    if( !isUserLoggedIn()) {
        adviseUser("You need to be logged in to remove orders");
    } else if (isOkToRemoveOrders(orders)) {
        orders.last().remove();
        adviseUser("Your last order has been removed");
        logAction(e, "order removed OK");
    } else {
        adviseUser("Your order was not removed");
        logAction(e, "order not removed");
    }
    remindUserToFloss();
    increaseProgrammerBrowniePoints();
    //etc...
}

Bir komut ile bildirim arasındaki ayrım, bu modelle, IMO ile yapmak için yararlı bir ayrımdır.

Yöntem / işlev çağrılarını kodlamak zorunda kalmamak için, kimin dinlediğini umursamadan etkinliği yayınlarsınız. Bu, yayıncıyı aboneden bağımsız kılarak uygulamanın 2 farklı bölümü arasındaki bağımlılığı (veya tercih ettiğiniz terim ne olursa olsun birleştirmeyi) azaltır.

İşte wikipedia'da belirtildiği gibi kuplajın bazı dezavantajları

Sıkıca bağlanmış sistemler, genellikle dezavantaj olarak görülen aşağıdaki gelişimsel özellikleri gösterme eğilimindedir:

1. Bir modüldeki bir değişiklik, genellikle diğer modüllerdeki değişikliklerin dalgalanma etkisini zorlar.
2. Modüllerin montajı, artan modüller arası bağımlılık nedeniyle daha fazla çaba ve / veya zaman gerektirebilir.
3. Belirli bir modülün yeniden kullanılması ve / veya test edilmesi daha zor olabilir çünkü bağımlı modüller dahil edilmelidir.

İş verilerini kapsayan bir nesne gibi bir şey düşünün. Yaş ayarlandığında sayfayı güncellemek için kodlanmış yöntem çağrısı vardır:

var person = {
    name: "John",
    age: 23,

    setAge: function( age ) {
        this.age = age;
        showAge( age );
    }
};

//Different module

function showAge( age ) {
    $("#age").text( age );
}

Şimdi kişi nesnesini showAgeişlevi de dahil etmeden test edemiyorum . Ayrıca, yaşı başka bir GUI modülünde de göstermem gerekirse, bu yöntem çağrısını kodlamam gerekir .setAgeve şimdi kişi nesnesinde 2 ilgisiz modül için bağımlılıklar vardır. Ayrıca, bu çağrıların yapıldığını ve hatta aynı dosyada olmadıklarını gördüğünüzde sürdürmek de zordur.

Aynı modül içinde, tabii ki doğrudan yöntem çağrılarına sahip olabileceğinizi unutmayın. Ancak iş verileri ve yüzeysel kullanıcı arabirimi davranışı, herhangi bir makul standartta aynı modülde yer almamalıdır.

PubSub uygulaması genellikle olduğu yerde görülür -

1. Bir olay veriyolu yardımıyla iletişim kuran birden çok portletin olduğu uygulama benzeri bir portlet vardır. Bu, aync mimarisinde yaratmaya yardımcı olur.
2. Sıkı kuplajla gölgelenen bir sistemde pubsub, çeşitli modüller arasında iletişim kurmaya yardımcı olan bir mekanizmadır.

Örnek kod -

var pubSub = {};
(function(q) {

  var messages = [];

  q.subscribe = function(message, fn) {
    if (!messages[message]) {
      messages[message] = [];
    }
    messages[message].push(fn);
  }

  q.publish = function(message) {
    /* fetch all the subscribers and execute*/
    if (!messages[message]) {
      return false;
    } else {
      for (var message in messages) {
        for (var idx = 0; idx < messages[message].length; idx++) {
          if (messages[message][idx])
            messages[message][idx]();
        }
      }
    }
  }
})(pubSub);

pubSub.subscribe("event-A", function() {
  console.log('this is A');
});

pubSub.subscribe("event-A", function() {
  console.log('booyeah A');
});

pubSub.publish("event-A"); //executes the methods.

"Yayınlamanın / Abone Olmanın Birçok Yüzü" makalesi iyi bir okuma ve vurguladıkları bir şey de üç "boyutta" ayrıştırmadır. İşte benim kaba özetim, ancak lütfen makaleye de bakın.

1. Uzay ayrıştırması. Etkileşen tarafların birbirini tanımasına gerek yoktur. Yayıncı kimin dinlediğini, kaç kişinin dinlediğini veya etkinlikle ne yaptıklarını bilmiyor. Aboneler bu etkinlikleri kimin yaptığını, kaç yapımcı olduğunu vb. Bilmiyor.
2. Zaman ayrımı. Etkileşimde bulunan tarafların etkileşim sırasında aynı anda aktif olmaları gerekmez. Örneğin, bir yayıncı bazı etkinlikleri yayınlarken abonenin bağlantısı kesilebilir, ancak çevrimiçi olduğunda buna tepki verebilir.
3. Senkronizasyon ayrıştırması. Yayıncılar, etkinlik üretirken engellenmez ve aboneler, abone oldukları bir olay geldiğinde geri aramalar yoluyla eşzamansız olarak bilgilendirilebilir.

Basit cevap Orijinal soru basit bir cevap arıyordu. İşte benim girişimim.

Javascript, kod nesnelerinin kendi olaylarını yaratması için herhangi bir mekanizma sağlamaz. Yani bir tür olay mekanizmasına ihtiyacınız var. Yayınla / abone ol kalıbı bu ihtiyaca cevap verecektir ve kendi ihtiyaçlarınıza en uygun mekanizmayı seçmek size kalmıştır.

Artık pub / sub kalıbına ihtiyaç olduğunu görebiliyoruz, o halde DOM olaylarını pub / sub olaylarınızı işleme şeklinizden farklı bir şekilde işlemeyi tercih eder miydiniz? Karmaşıklığı azaltmak adına ve endişelerin ayrılması (SoC) gibi diğer kavramlar için her şeyin tek tip olmasının faydasını görebilirsiniz.

Yani paradoksal olarak, daha fazla kod, endişeler arasında daha iyi bir ayrım yaratır ve bu da çok karmaşık web sayfalarına kadar ölçeklenebilir.

Umarım birisi ayrıntılara girmeden bunu yeterince iyi bir tartışma bulur.