“歌斐遵守規則”
import "github.com/hyperjumptech/grule-rule-engine"
Grule是 Go (Golang) 程式語言的規則引擎庫。受到廣受好評的 JBOSS Drools 的啟發,並以更簡單的方式完成。
與Drools一樣, Grule有自己的DSL或領域特定語言。
以下是 Drools 的 DRL 或 Drools 規則語言的範例:
rule "SpeedUp"
salience 10
when
$TestCar : TestCarClass( speedUp == true && speed < maxSpeed )
$DistanceRecord : DistanceRecordClass()
then
$TestCar.setSpeed($TestCar.Speed + $TestCar.SpeedIncrement);
update($TestCar);
$DistanceRecord.setTotalDistance($DistanceRecord.getTotalDistance() + $TestCar.Speed);
update($DistanceRecord);
end
Grule的GRL如下:
rule SpeedUp "When testcar is speeding up we keep increase the speed." salience 10 {
when
TestCar . SpeedUp == true && TestCar . Speed < TestCar . MaxSpeed
then
TestCar . Speed = TestCar . Speed + TestCar . SpeedIncrement ;
DistanceRecord . TotalDistance = DistanceRecord . TotalDistance + TestCar . Speed ;
}
沒有比 Martin Fowler 撰寫的文章更好的解釋了。您可以在此處閱讀這篇文章(RulesEngine,作者:Martin Fowler)。
取自TutorialsPoint網站(略有修改),
Grule規則引擎是一個生產規則系統,它使用基於規則的方法來實現專家系統。專家系統是基於知識的系統,它使用知識表示將獲得的知識處理成可用於推理的知識庫。
產生式規則系統是圖靈完備的,重點在於知識表示,以簡潔、明確和聲明性的方式表達命題和一階邏輯。
生產規則系統的大腦是一個推理引擎,可以擴展到大量規則和事實。推理引擎將事實和數據與生產規則(也稱為生產或只是規則)進行匹配,以推斷出導致採取行動的結論。
產生式規則是一個由兩部分組成的結構,它使用一階邏輯對知識表示進行推理。業務規則引擎是一種在運行時生產環境中執行一個或多個業務規則的軟體系統。
規則引擎允許您定義“做什麼”而不是“如何做”。
(也取自TutorialsPoint)
規則是知識片段,通常表示為「當某些條件發生時,則執行某些任務」。
When
< Condition is true >
Then
< Take desired Action >
規則最重要的部分是它的when 部分。如果滿足when部分,則觸發then部分。
rule < rule_name > < rule_description >
< attribute > < value > {
when
< conditions >
then
< actions >
}
規則可以輕鬆地表達困難問題的解決方案並得到驗證。與程式碼不同,規則是用不太複雜的語言編寫的;業務分析師可以輕鬆閱讀和驗證一組規則。
資料駐留在網域物件中,業務邏輯駐留在規則中。根據項目的類型,這種分離可能非常有利。
透過使用規則,您可以建立可執行的知識庫(知識庫)。這是商業政策的單一事實點。理想情況下,規則易於閱讀,也可以作為文件。
由於業務規則實際上被視為資料。根據業務的動態性質調整規則變得微不足道。無需像正常軟體開發那樣重新建立程式碼或部署 - 您只需推出規則集並將其應用到知識庫。
使用規則引擎可以更好地解決以下情況:
必須評估事實以提供某種現實世界結論的專家系統。如果不使用 RETE 風格的規則引擎,人們將編寫一組級聯的if
/ else
語句,而這些評估方式的組合的排列將很快變得無法管理。基於表的規則引擎可能就足夠了,但它仍然更容易受到更改的影響,並且編碼起來也不是很容易。像 Grule 這樣的系統允許您描述系統的規則和事實,使您無需描述如何根據這些事實評估規則,並向您隱藏大部分複雜性。
評級系統。例如,銀行系統可能希望根據客戶的交易記錄(事實)為每個客戶建立「分數」。我們可以看到他們的分數變化,這取決於他們與銀行互動的頻率、轉入和轉出的金額、支付賬單的速度、應計的利息、為自己或為銀行賺了多少錢,以及很快。規則引擎可以由開發人員提供,然後事實和規則的規範可以由銀行客戶分析部門內的主題專家提供。將這些不同的團隊解耦,將責任放在應有的位置。
電腦遊戲。玩家狀態、獎勵、懲罰、傷害、分數和機率系統是規則在大多數電腦遊戲中發揮重要作用的許多不同範例。這些規則可以以非常複雜的方式交互,常常以開發人員沒有預見的方式交互。透過使用腳本語言(例如 Lua)對這些動態情況進行編碼可能會變得相當複雜,而規則引擎可以幫助極大地簡化工作。
分類系統。這其實是上述評級系統的概括。使用規則引擎,我們可以對信用資格、生化識別、保險產品的風險評估、潛在的安全威脅等進行分類。
意見/建議系統。 「規則」只是另一種數據,這使得它成為另一個程式定義的主要候選者。這個程式可以是另一個專家系統或人工智慧。規則可以由其他系統操縱,以處理新類型的事實或新發現的有關規則集要建模的域的資訊。
還有許多其他用例可以從規則引擎的使用中受益。上述案例僅代表一小部分潛在案例。
然而,重要的是要記住,規則引擎當然不是靈丹妙藥。有許多替代方案來解決軟體中的「知識」問題,並且應該在最合適的地方使用它們。例如,如果一個簡單的if
/ else
分支就足夠了,就不會使用規則引擎。
還有一點要注意:一些規則引擎的實現非常昂貴,但許多企業從中獲得瞭如此多的價值,以至於運行它們的成本很容易被該價值所抵消。即使對於中等複雜的用例,強大的規則引擎可以解耦團隊並降低業務複雜性的好處似乎也很明顯。
文件頁面在這裡
若要深入了解本教學課程,請參閱 Github 上的 Wiki 文件。
Loading rules into KnowledgeBase
:
要將100
規則載入到知識庫中,每個操作需要99342047 ns/op
(取最高值),這等於~99.342047ms
和 ( 49295906 B/op
) ~49.295906MB
內存
要將1000
規則載入到知識庫中,每個操作需要933617752 ns/op
(取最高值),等於~933.617752ms
和 ( 488126636 B/op
) ~488.126636
內存
Executing rules against a fact
:
為了針對 100 條規則執行一個事實,Grule 引擎花費了~9697 ns/op
(以最高值作為基礎),這幾乎不到~0.009697ms
和3957 B/op
,這相當快。
為了針對 1000 條規則執行事實,Grule 引擎花費了~568959 ns/op
(以最高值作為基礎),幾乎不到~0.568959ms
和293710 B/op
這也相當快。
您可以在此處閱讀詳細報告
是的。我們需要貢獻者來使 Grule 變得更好並且對開源社群有用。
如果你真的想幫助我們,只需Fork
專案併申請 Pull Request 即可。請閱讀我們的貢獻手冊和行為準則