複雜邏輯的任何設計模式/編碼方法？

Question

我不得不清理在線大學申請的代碼。沒有什麼特別的錯，但它很複雜。不同的學位課程有不同的條件，費用，所需的文件和問題。最重要的是，來自軍方的學生獲得不同的費用，而以前的學生不收費並跳過步驟。

很明顯，所有這些邏輯都會變得相當複雜 - 並且會導致錯誤。我想知道是否有設計模式或編碼方法可以幫助組織邏輯。我使用PHP，並不重要。

strategy pattern似乎有最大的潛力，但在我看來，我需要戰略之上的策略。

我想「業務邏輯」的領域可能至少部分覆蓋了這一點，但是搜索並沒有顯示任何優雅的編碼方法的使用。

Answer 1

如您所說，Stategy模式聽起來好像可能適合賬單 - 但是有了一點複雜的邏輯，您可能希望將它放在domain model中，而不是您現在可能使用的transaction script。

福勒的書Patterns of Enterprise Application Architecture對整個關於你的應用程序的思考領域有着很好的解釋（他建議你從那開始並從那裏開始工作）。

正如其他人所說，單元測試總是有幫助！

Answer 2

我認爲模式的組合會有幫助。 Fowler's Domain Model pattern旨在馴服複雜的領域邏輯。使用分層架構模式是另一種選擇，如POSA1中所述。戰略模式似乎也是定義一系列相關算法的好主意。

Answer 3

作爲一個起點，你有沒有遇到過unit testing？ PHP單元測試的快速谷歌提出了http://www.phpunit.de/。

作爲一個起點，你應該看看你是否可以單元測試你現有的代碼。這樣，您就有信心完成它的目標，並且應該能夠在未來進行更改，而不用擔心打破現有邏輯。同樣，一旦你在現有的代碼上進行了單元測試，你就可以改變自己的置信度來改進邏輯。

Answer 4

應用一些設計模式並不能解決所有問題，儘管有些可能有助於更好地組織代碼。如果您想要減少錯誤，然後實施某種自動化測試，請參閱「測試驅動開發」和「持續集成」方法。

Answer 5

我不相信這種問題是由一個或多個模式來解決的。在某種程度上，「只是設計」 - 你建立一個設計，發現關係和彈性點，例如面向對象技術（例如）的幫助，並在此時模式發揮作用。

多年來，我觀察到許多嘗試通過「不寫代碼」來解決這些問題。那就是我們找到了一些方法將業務邏輯外化爲比代碼更可塑的東西。因此，它可能只是你外在化的收費規則：

Thinking 101 Standard $100 Alumni $50 Ex-Military $0 
    Hard Sums  Standard $500 Alumni $100 Ex-Military $0 

現在改變這些規則是一個配置的變化，而不是一個代碼更改。這種數據驅動的方法可能比代碼更好。

然後你想外部化邏輯，所以規則引擎出現。

和externalise處理邏輯，因此我們得到BPEL。

我看到了所有這些方法的成功，但......在效果已邏輯某處外在這樣兩個問題依然存在：

1. 如何容易，你可以測試這個邏輯是什麼？您可能沒有減少所需的測試數量。
2. 您如何管理這種外部邏輯的生命週期？您是否可以試用它，因爲可能是一個小客戶羣體，當它被發現是錯誤的時候，它會回滾它？允許多個版本同時在線？

這東西還是軟件，它真的是僞裝的代碼。