固定條件

　　一般來說，固定條件就是一種在給定的上下文中始終為 true 的條件。 在應用于面向?qū)ο蟮能浖r，固定條件指示一種針對類的各個實例始終為 true 的條件。 固定條件是一種強大的工具，每當給定類的任何實例的狀態(tài)失效時，它都會及時通知您。 換言之，固定條件協(xié)定正式定義據(jù)以推測類的實例處于良好狀態(tài)的條件。 雖然聽起來很重要，但這只是在通過類對業(yè)務域建模時要先了解后實施的第一個概念。 域驅(qū)動設計 (DDD) 是目前用于為復雜業(yè)務方案建模的成熟方法，而且可在設計時為固定條件邏輯分配一個重要位置。 實際上，DDD 極力建議您永遠都不要處理處于無效狀態(tài)的類的實例。 同樣，DDD 還建議您編寫返回有效狀態(tài)的對象的類的工廠，并且您的對象在每次操作后都以有效狀態(tài)返回。

　　DDD 是一種方法，協(xié)定的實際實施應該由您來完成。 在 .NET Framework 4 中，代碼協(xié)定可最大限度地減少您的工作量，有效幫助您成功地進行實施。 我們來更詳細地了解一下 .NET Framework 4 中的固定條件。

　　固定條件邏輯在哪里？

　　固定條件是否在某種程度上與優(yōu)秀的對象建模和軟件設計有關？ 深入了解域至關重要。 深入了解域自然會指導您找到您的固定條件。 有些類根本不需要固定條件。 從根本上說，缺乏固定條件并不是一種警告信號。 對應該包含什么內(nèi)容以及應該執(zhí)行什么操作沒有限制的類就沒有固定條件。 如果這是您的分析得出的結果，那么再好不過了。

　　假定有一個類代表要發(fā)布的新聞。 該類可能有標題、摘要和發(fā)布日期。 此處的固定條件在哪里？ 這取決于業(yè)務域。 發(fā)布日期是必需的嗎？ 如果是，則您應該確保新聞始終有有效日期，而“有效日期”的定義也來源于上下文。 如果日期是可選的，則您可以保存一個固定條件，并確保先驗證屬性的內(nèi)容，然后再將該屬性應用于要在其中使用它的上下文中。 標題和摘要也可以以同樣的方式處理。 既沒有標題也沒有內(nèi)容的新聞是否有意義？ 如果這在您正在考慮的業(yè)務方案中有意義，則您有一個無固定條件的類。 如果沒有意義，則要準備好添加幾項檢查，以防標題和內(nèi)容為空。

　　更常見的情況是，無任何行為且充當松散關系數(shù)據(jù)的容器的類可能缺乏固定條件。 如有疑問，我建議您對該類的每個屬性都問問“我是否可以在這里存儲值？”，而不需要考慮屬性是公用的、受保護的還是私用的（只要是通過方法設定的）。 這樣做應該有助于具體了解您是否會遺漏模型的要點。

　　與設計的許多其他方面一樣，如果在設計過程的早期查找固定條件，則會更富有成效。 在開發(fā)過程的晚期添加固定條件始終都是可行的，但這樣做會增加您在重構方面的成本。 如果要這樣做，則必須小心，當心回歸。

　　代碼協(xié)定中的固定條件

　　在 .NET Framework 4 中，類的固定條件協(xié)定是對該類的任何實例始終應為 true 的條件的集合。 向類中添加協(xié)定時，前置條件用于在該類的調(diào)用程序中查找錯誤，而后置條件和固定條件則用于在類及其子類中查找錯誤。

　　您需要通過一個或多個專用的方法來定義固定條件協(xié)定。 這類方法是實例方法，它們是私有的，返回 void 且有特殊屬性（ContractInvariantMethod 屬性）加以修飾。 此外，固定條件方法不得包含定義固定條件所需的調(diào)用之外的代碼。 例如，您不能在固定條件方法中添加任何類型的邏輯，無論邏輯是否純凈都不行。 您甚至不能添加只是用于記錄類的狀態(tài)的邏輯。 下面介紹如何為類定義固定條件協(xié)定：

NET技術：代碼協(xié)定中的固定條件和繼承，轉(zhuǎn)載需保留來源！

鄭重聲明：本文版權歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。