? ? 數據大體上可以分為 接口類數據 和非接口類數據。前者意味著契約，后者關于實現，后邊提及數據，一般指后一種。數據還可以從 生命周期，聚合根，等角度分析。

基礎行為(basic behavior，bbhv)

? ? 數據拆分還有一個角度業(yè)務的角度。抽象數據，即從算法(或業(yè)務邏輯)角度描述應該存在的一個東西，缺了它，很多行為就毛將焉附了，它聚合了一簇相關的行為。OO方法看，這抽象數據應該封一個類。

? ? 數據類只get/set就貧血；涉及太復雜流程，弄個數據團又成了上帝類，這個權衡把握實際上很難給個一刀切的標準。實際上某個特定系統(tǒng)在設計之初，就應該給出適合它的框架結構幫助達成基本一致的拆分，這種結構可以另文討論。

? ? 從行為分類的角度看，這些行為是基礎行為(basic behavior，bbhv)。bbhv，是編程的基本單位(基本單位絕不是單條語句，單條語句什么也不是！)，它描述的是在一個特定場景下處理某個原子操作的實現，它直接訪問某個抽象數據的實現。不涉及多個數據間的協(xié)作，也不涉及不同場景下的擇路。bbhv的實現中，一般不會用到if/else。

具體行為(concrete behavior，cbhv)

? ? 有了大量的bbhv，需要把它們組合在一起，完成業(yè)務邏輯的描述。這種描述流程組合的行為，可以稱作框架或過程。我喜歡稱之為具體行為，cbhv，而框架(frame)則專指組件/模塊最頂層的過程。cbhv負責完成系統(tǒng)的組合，只描述分解的步驟，也就意味著它有不同的層次；cbhv不涉及具體的數據，只引用聚合根的ID，這樣即便在c語言中也可以比較容易的實現靈活的組合。

? ? cbhv中對組合的控制元素，可以包括loop 和 break 機制(如因失敗或超時的退出)，但不應該包括擇路。不包括擇路的理由是：

? ? 其一，如果允許cbhv擇路組合過程的復雜度立刻會激增以致難以控制；

? ? 其二，cbhv中希望體現的組合的過程就會被湮沒在大量的擇路中；

? ? 其三，擇路是應該被獨立設計的變化方向。

? ? 這樣，就需要一種特殊的行為來描述選擇了。留意看的話，在bbhv的描述中實際上也欠缺關于選擇的實現。

抽象行為(abstract behavior，abhv)

? ? 一個行為，完成某個邏輯功能，但在不同的場景下有不同的實現。這個行為就是抽象行為。抽象行為在軟件分層結構中，描述的是高層定義的函數(行為)接口。抽象行為的選擇器(選擇哪個實現)，是? 狀態(tài)/場景/開關 這一類特殊的數據決定的。這種數據也是拆分其它數據的理由。選擇的變化周期，和引用它的cbhv并不相同。從業(yè)務邏輯看cbhv/bbhv的變化方向和abhv并不相同，前者隨業(yè)務流程或具體數據實現形式變化，后者只隨狀態(tài)變化。

? ? abhv的具體實現可以是多個bbhv，也可以是多個cbhv，或者兩者的混合。選擇器從中擇一。從邏輯上不排斥它的實現也可以是abhv，但這情況下要給出為何不將它們合并成一個abhv的充分理理由。由于選擇條件使用應該具有一致性，所以這種理由其實不好找。

實現組合編程

? ? abhv的設計也是管理系統(tǒng)復雜度的關鍵所在，它沒有b/c那么直觀，實際上這三種行為都需要細致的拆分和抽象。

這三種行為各司其職：

? ? bbhv負責實現，生產基礎部件；
? ? cbhv負責組合，把零件拼裝起來；
? ? abhv負責選擇，指導選擇合適的零件實現一致的功能。

最終實現組合式編程的目的。巧的很，行為的名字叫 a/b/c behavior，所以本文也可以叫? 《行為ABC》。