canonical

    程序中大量的工作其實都是在定義結構以及結構之間的關系. 一般情況下我們應該識別出結構,并把它們封裝到函數,對象和組件中去. 但是封裝并不永遠都是有利的. 將某個結構獨立出來, 在某種程度上也就割裂了它和其他元素之間的關系, 這會引發結構融合的障礙, 也會造成思維上的負擔. 事實上如果程序整體具有足夠的可理解性和概念穩定性, 我們并不需要獨立識別出什么子部分. 一個簡單的例子是數組循環. 一般情況下我們應該盡量把循環查找等操作封裝到函數中, 避免多重循環嵌套時產生過于復雜的代碼塊. 但是如果數組或者語言本身提供了each, map等函數式操作符,則這種封裝需求就大大減弱了.
    隨著系統結構的日益復雜化, 在系統中會積累大量的背景知識.此時當我們需要完成一個功能的的時候, 往往不再需要指定所有的信息, 而只需要指定背景知識之外的部分信息即可. 例如在界面上通過一個分頁表格來顯示實體列表這樣一個功能, 在Witrix平臺中通過模型驅動的標準頁面即可自動完成. 一般的定制需求往往是過濾顯示部分數據, 在表格行上增加一些操作按鈕, 定制表格的表頭等. Witrix平臺實現這些需求并不需要封裝出一個獨立的表格組件, 調用它的屬性修改方法等, 而是把定制部分嵌入到BizFlow的配置中, 這里并沒有明確的結構界限.
  <biz id="default">
    <filter>
       <eq name="status" value="1" />
    <filter>
     <tpls>
        <tpl id="thead>
         <thead>
          <tr rowspan="2">...</tr>
          <tr>...</tr>
         </thead>
        </tpl>
        <tpl id="rowOps">
          <ui:FlatButton .../>
        </tpl>
     </tpls>
      其他與表格無關的信息
  </biz>
  注意到對于我們理解業務而言, 我們并不需要知道表格具有分頁, 排序, 隔行變色等功能. 所有和業務相關的代碼聚集到BizFlow文件中, 它們構成一個可以獨立理解的整體, 在此過程中也通過背景知識實現了大量結構的消解.