>[success] # 書中的登錄案例 ~~~ 1.書中舉了一個例子 ：假如我們正在開發一個商城網站，網站里有 header 頭部、 nav 導航、消息列表、購物車等模，這幾個模塊的渲染有一個共同的前提條件， 就是必須先用 ajax 異步請求獲取用戶的登錄信息。 2.上面的場景就是一對多，一就是登陸接口返回的數據，對應多個需要他的地方 3.將這個場景轉換成發布訂閱模式，一個用來保存訂閱者緩存的發布者對象，一個 執行發布消息觸發的地方 ~~~ >[danger] ##### 不使用發布訂閱模式代碼寫法如下 ~~~ 1.當登陸成功的時候需要執行四個地方，分別是導航頭像，header標簽里的頭像， 刷新消息列表，刷新購物車，這種寫法在工作中很常見，'js設計模式與開發的作者' 提出了兩個場景讓這種常見的寫法變得直擊心靈 1.1 如果當后續其他開發人員增加了一個收貨模塊，需要在獲取用戶信息的時候加載一下 就需要找到最開始寫這個登錄接口的人，告訴他在這個'login.succ'中接著添加一個收貨 模塊的加載 1.2.這種開發模式叫'針對具體實現編程'書中作者對這類的編程不贊同,會出現另外一個問題， 假如你是開發登錄模塊，但你的登陸模塊出現了現在的問題需要加載其他模塊的方法，你 就需要了解解 header 模塊里設置頭像的方法叫setAvatar、購物車模塊里刷新的方法叫 refresh， 不僅如此你還不能隨意改變setAvatar 的方法名，它自身的名字也不能被改為 header1、header2。 '這種耦合性會使程序變得僵硬' ~~~ ~~~ login.succ(function(data){ header.setAvatar( data.avatar); // 設置 header 模塊的頭像 nav.setAvatar( data.avatar ); // 設置導航模塊的頭像 message.refresh(); // 刷新消息列表 cart.refresh(); // 刷新購物車列表 }); ~~~ >[danger] ##### 發布訂閱模式進行改進 ~~~ 1.用發布—訂閱模式重寫之后，對用戶信息感興趣的業務模塊將自行訂閱登錄成功的消息事件。 當登錄成功時，登錄模塊只需要發布登錄成功的消息，而業務方接受到消息之后，就會開始進行 各自的業務處理，登錄模塊并不關心業務方究竟要做什么，也不想去了解它們的內部細節 ~~~ * 需要觸發通知 ~~~ $.ajax( 'http:// xxx.com?login', function(data){ // 登錄成功 login.trigger( 'loginSucc', data); // 發布登錄成功的消息 }); ~~~ * 將各個模塊的訂閱者假如發布者的緩存列表中 ~~~ 1.以后在需要有要在登錄模塊調用方法的地方你只需要加入自己所需要通知對象 進去即可。 ~~~ ~~~ var header = (function(){ // header 模塊 login.listen( 'loginSucc', function( data){ header.setAvatar( data.avatar ); }); return { setAvatar: function( data ){ console.log( '設置 header 模塊的頭像' ); } } })(); var nav = (function(){ // nav 模塊 login.listen( 'loginSucc', function( data ){ nav.setAvatar( data.avatar ); }); return { setAvatar: function( avatar ){ console.log( '設置 nav 模塊的頭像' ); } } })(); ~~~ >[danger] ##### 總結 ~~~ 1.這里我個人的理解是，你的模板決定了其他模塊的方法加載，嘗試使用發布訂閱模式， 而不是我自己寫了一個模塊，這個模塊中有一個方法加載的時候需要調用你自己這個 模塊中的其他方法你來使用'發布訂閱模式' ~~~