業務很簡單：乙個事件 上報 然後會發簡訊通知和郵件通知
1 第一種物件導向設計 ssh結構
public class event
/*** 該介面為建立介面
* 凡是持久化動作需實現此介面
* */
public inte***ce icreater
/*** 此介面為本系統的動作
*/public inte***ce iputer extends icreater
/*** 此介面為外系統的動作
*/public inte***ce igeter extends icreater
/** 上報者物件
* 被觀察者
* 資訊建立者
*/public class upsender extends observable implements iputer}/*
* 發簡訊物件
* 觀察者
*/public class telsender implements observer}/*
* 發郵件物件
* 觀察者
*/public class emailsender implements observer
}public class service
}
優點 最熟悉的方式 可根據變化點進行抽象封裝以擴充套件
缺點 物件沒有生命 需要把隱含物件找出來 或者就按照3層結構寫介面和**
2 基於事件通知的領域驅動設計的設計
public class eventprocesser
}public class event }/*
* 發簡訊物件
*/public class telsender
}public class telsendevent extends domainevent}/*
* 發郵件物件
*/public class emailsender extends domainevent
}public class emailsendevent extends domainevent}/*
* 上報事件
*/public class upsendevent extends domainevent
public class service
}
從上面的例子，我們可以清楚的看到領域物件之間沒有相互引用，完全通過事件來實現相互協作。比如父物件通知子物件，子物件通知父物件，乙個事件通知乙個或多個同型別或不同型別的物件，等等。要實現任何乙個業務場景，我們需要做的事情一般是：
1）通知**事件處理器處理某個事件（如果該事件是框架沒有提供特定的業務事件，則需要自己定義）；
2）領域物件響應該事件，通過定義私有的響應函式來實現響應；
3）在領域模型內部，告訴框架事件及響應者之間的對映關係，並告訴框架有哪個或哪些物件會去響應，它們的唯一標識是如何從事件中獲取的；
通過這三個步驟，我們就可以輕鬆簡單的實現各種領域物件之間的協作了。而且需要強調的是，通過這樣的方式，可以充分體現出領域物件是「活」的這個概念。因為所有的領域物件的事件響應函式都是私有的，也就是領域物件自己的行為別的領域物件無法去呼叫，而都是由乙個「**事件處理器」去統一呼叫。這樣的效果就是，任何乙個領域物件都會「主動」去響應某個事件，這樣就從分體現出了「活」物件的概念了。在我看來，這才是真正的物件導向程式設計，因為所有的物件都是主動參與到某個業務場景中去的。
優點：高度可擴充套件性，因為是基於事件訊息機制的，把領域物件之間的耦合度降到了最低
缺點：可維護性方面可能有問題，會出現超大類 還有習慣問題
react事件的多種寫法
類裡面的函式,放在類的原型物件上，供例項物件呼叫 class person 一般方法 speak onclick 通過this這個例項物件獲取handleclick函式 此時handleclick是自己執行的，所以this指向undefined 定義箭頭函式this指向定義時的this，class ...
快速排序的多種思路實現
快速排序的多種思路實現 兩邊想中間靠攏 兩邊想中間靠攏，當a left key時，兩者交換 int partsortbothsize int a,int left,int right if begin if a begin a right return right 挖坑法 挖坑法left right...
演算法 求Fibonacci的多種思路和演算法
能夠直觀地看出演算法之間效率的區別 include include include using namespace std brief fibonacci數，二分遞迴版 param n 求第n項fibonacci數 discription 雖然簡潔明瞭，但是屬於2 n的複雜度，這是無法忍受的 並且重...