“函式式”和“物件導向式”在許可權引擎中是如何融為一體的？

把控“資源”和“功能”的正交關係
現在有這樣一個問題：比如臥室裡有“空調”、有“電風扇”，這兩種資源都有“降溫”的能力（功能）。
我想直接控制“降溫”許可權，而不是分別控制“使用空調降溫”和“使用電風扇降溫”怎麼辦呢？這裡的“降溫”可以認為是Function，而“使用空調降溫”和“使用電風扇降溫”可以認為是Operation，因為它們繫結到了資源上。“降溫”能力集是比“使用空調降溫”和“使用電風扇降溫”能力集更大的能力集。
把函式固定在物件上，先定位物件然後再定位函式，將物件視為函式的耦合作用域（函式中傳入的this物件）這是物件導向的方法論。把函式和物件分開然後透過（Function, Input, Output）組合成三元組這是函式式方法論。
在OO世界中，由於Function已經被繫結到Object和ObjectType上去了，所以當房間裡有“空調”和“電風扇”這兩種降溫資源的時候我們若要控制某個主體不能降溫的話就只有分別控制他不能“使用空調降溫”和“使用電風扇降溫”了。
試試透過變換資源樹的結構能否解決上面那個問題呢？
+製冷裝置
----電風扇（ResourceType）
--------電風扇降溫（overwrite Operation）
--------風扇1（電風扇型別object1）
--------風扇2（電風扇型別object2）
----空調（ResourceType）
--------空調1（空調型別object1）
--------空調降溫（overwrite Operation）
----降溫（Operation）
現在，如果我們直接不讓某個主體不能使用“製冷裝置”下的“降溫”功能的話是可以做到使他既不能“使用空調降溫”也不能“使用電風扇降溫”的。
但是，空調除了是“製冷裝置”還是“制熱裝置”。重繪一下上圖的樹會是這樣。
+製冷裝置
----電風扇（ResourceType）
--------電風扇降溫（overwrite Operation）
--------風扇1（電風扇型別object1）
--------風扇2（電風扇型別object2）
----空調（ResourceType）
--------空調1（空調型別object1）
--------空調降溫（overwrite Operation）
----降溫（Operation）
+制熱裝置
----空調（ResourceType）
--------空調1（空調型別object1）
--------空調製熱（overwrite Operation）
----制熱（Operation）

融合“物件導向式”和“函式式”
問題出來了：“空調”節點在資源樹上出現在了兩個位置。這違反了樹形結構，違反了構造定理，所以我們錯了。
我們得從資源樹上“剪掉”製冷裝置和制熱裝置這兩個節點，得把它們放入新的維度中去。那個新的維度是什麼？是函式維度。上面我們遇到的問題是因為我們鑽到資源樹這一棵樹中去了，“製冷裝置”“制熱裝置”中的“裝置”是資源，而“製冷”和“制熱”是函式。
從資源的角度永遠沒辦法解決空調既出現在製冷裝置節點下又出現在制熱裝置節點下這個問題。資源和功能組合起來後就很好的解決了。（使用空調製冷"Operation"，製冷"Function"）（使用空調製熱"Operation"，制熱"Function"）（使用電風扇製冷"Operation"，製冷"Function"）（使用電熱扇制熱"Operation"，制熱"Function"）。
函式（能力、運動、時間）是適合組合到資源（空間）上的，只有與特定型別的資源十分緊密依賴的函式才是可以沿著資源樹繼承的。
在Anycmd這個開源許可權引擎中斷言過（Function, Function）這種型別的二元組是有意義的，現在終於幾乎確定找到了它的意義。（使用空調製冷"Operation"，製冷"Function"）這個二元組就是（Function, Function）型別的二元組（Operation集是Function集的子集，Operation是特殊的Function）。

（Function, Function）型別的Privilege二元組
（Function, Function）這種二元組目的是建立Function之間的層次關係。
在appSystem節點上（appSystem節點是根，雖然在空調和電風扇共同的任意父節點上都行但最佳應在appSystem這個根節點上，根節點是Global物件）新增一條命名為“製冷”的Operation記錄。然後建立（使用空調製冷"Operation"，製冷"Function"）（使用空調製熱"Operation"，制熱"Function"）（使用電風扇製冷"Operation"，製冷"Function"）這種（Function, Function）型別的二元組合。表示“電風扇製冷”和“空調製冷”繼承“製冷”，從而安全引擎鑑權當前請求“空調製冷”的主體是否有許可權的時候找到“空調製冷”這條Function記錄的父級記錄“製冷”，然後鑑權是沿著Function的層次進行一級一級向下進行的，如果當前主體沒有“製冷”許可權就直接沒有許可權了，如果有“製冷”許可權再接著驗證“空調製冷”許可權。


需要提及的是：
製冷”這條function記錄並不對應實際的程式設計師書寫的功能程式碼，而只是一條記錄，這條記錄的目的只是為製冷這種功能取個名字生成一個標識，然後用來和業務系統中的繫結在資源上的那些“操作”（繫結在資源上的Function稱Operation）建立（function, function）型別是組合從而表達功能間的層次關係。

許可權引擎在智慧傢俱領域的應用：
上面那種邏輯在智慧家居中可以應用。1 比如家長擔心使用電風扇製冷存在安全風險（擔心小孩子會將線頭布條輸入旋轉的電風扇中），所以家長主體可以將家居這個appSystem環境設定為當只有小孩子一個人在家的時候系統拒絕小孩主體開啟電風扇，但允許小孩子開啟空調；2 當家居中的主體數量大於3人時空調和電風扇可以被同時開啟，當少於3人時只能開啟其中之一。即使終端使用者有任意複雜的授權和鑑權需求Anycmd開源許可權引擎幾乎都能滿足。