前面我們已經對領域內的名詞進行了抽取，並且已經確定了業務流程中參與的核心物件。
但是物件只是靜態的描述，系統中往往會有很多的業務操作，偏演算法的，之前我們說過
領域內的物件往往是比較穩定不怎麼變化的，但是，業務的流程以及業務操作這些是往往
千變萬化，防不勝防，那麼我們如何去及時發現這些系統內變化點，並且如何使用物件導向
的方式去抽象，封裝它呢？，下面就簡單介紹我們的一些經驗，也在此記錄一下。
關注系統中的變化點或者說業務的流程中某個節點的多變的演算法，
提供系統的可維護性和擴充套件性。
先說步驟，步驟後面跟著一些場景進行解析，試著理解步驟。
這是第一步也是關鍵的一步，如果你連這個系統中的變化點都找不到，下面的工作也就
無從談起，所以我們在這個階段就要去細心觀察找出那些業務的變化點，
一般的我們可以從產品的原型中，產品的溝通中可以找到：
關注那些從描述上看起來不一樣，卻又是在做同一件事的場景。
找出這個場景或者演算法每次而且每條都出現的領域名詞和沒有限定詞的動詞，其他的全部可以忽略。
簡單的說就是把場景中的不斷出現的領域名詞都刪除掉，留下動詞。
根據上一步的操作，我們對場景中的動詞需要進行抽象一下，使用乙個動作統一概括。
將這個動作作為乙個介面存在，確定這個介面中的方法用來做什麼以及它的輸入，輸出。
說白了就是定義乙個函式的名稱，引數，返回值。
一般來說輸入的要是抽象中每次都出現的名詞，輸出是這個抽象需要的內容。
並不是說乙個介面只能有乙個方法，實際上，有些方法是成雙成對，甚至是成幾對出現的。
如果發現兩個介面合在一起剛好可以表達乙個完整的事情就可以將這兩個介面合併成乙個介面。
購買xx商品得到xx商品的服務
購買，服務
ibuy
介面中的方法：
方法名稱：gotobuy
引數：商品
執行：完成購買
返回：空
iservice
方法名稱：supply
引數：商品
執行：商品提供的服務
返回：空
我們會發現但凡我們需要增加乙個商品都需要實現這兩個介面，這個時候就說明我們可以
將這兩個介面抽取成乙個介面，這就是聚合介面。
這個場景的變化點就是使用者可以使用多種方式完成支付。
使用xx方式完成訂單支付
這個場景強調的動作是支付，所以動詞應該就是：去支付
但是，我們知道每乙個支付都需要我們提供給乙個支付完成的**供支付平台通知支付結果，
所以這裡要新增乙個動作：完成支付
介面中的方法：
方法名稱：gotopay
引數：訂單
執行：完成購買
返回：空
方法名稱：finish
引數：訂單
執行：完成購買
返回：空
介面有了，但是我們怎麼更好組織它呢？
一般的場景我們可以採用以下方案：
如果這些介面的具體實現在同一時刻只能出現乙個具體演算法，這些演算法又可以平行替換，
我們就可以參考「策略模式"去設計。
如果這些介面的具體實現在同一時刻有可能需要組合一起去完成某個功能這就是序列，
我們可以使用」職責鏈模式「去設計。
如果這些演算法之間有一些公用的邏輯，業務，演算法我們可以考慮使用，模板模式，裝飾模式去解決重複問題，
讓我們的設計更加合理有擴充套件性。
物件導向 物件的使用
在程式設計中先定義類，才能宣告類的物件。class oldboystudent school oldboy 語法 在類名後加括號，與呼叫函式寫法相同。s1 oldboystudent 查print s1.school oldboy 增s1.age 1 print s1.age print s1.di...
JS物件導向使用物件導向進行開發
對 js 中的物件導向的基礎進行講述,初體驗使用物件導向進行開發 物件導向的概念及特性 用物件導向的方式解決簡單的標籤建立例項 物件導向就是使用物件 物件導向開發就是使用物件開發 面向過程就是以過程的方式開發 物件導向是面向過程的封裝 抽象性如果需要用一物件來描述乙個資料,那就需要抽取這個物件的核心...
jQuery物件導向定製業務框架開發
jbase.js 業務框架基類 class jbase description 定製框架基類 author fangxianghua var jbase function function extend description 父子類繼承函式 author fangxianghua jbase.ex...