2011-08-23 90 views
2

我有一個場景,我正在處理MailItems隊列。一旦我處理了每個MailItem,我需要更新MailItem的狀態。更新狀態的邏輯非常複雜。我的想法是,我不應該將邏輯本身封裝在MailItem類中,而是將其封裝在單獨的類中,以便將來進行維護。我應該如何實現複雜的業務邏輯?

因此,我的問題是做這件事的最好方法是什麼?

我考慮了規範模式。我對這個模式的研究是它的鉸鏈定義爲ISpecification界面如下:

public interface ISpecification<T> 
{ 
    bool IsSatisfiedBy(T candidate); 
} 

我的問題是,我在這種特殊情況下的邏輯不僅是由候選對象的內部狀態的影響,也受到一個外部價值,我需要通過考慮的邏輯。

所以,在我的MailItem方法簽名必須是這個樣子:

public void ChangeStatus(bool mailSentSuccessfully) 

標準ISpecification接口並不滿足通過在外部值。我是否簡單地「彎曲」標準實現,或者這是否打破了模式定義的「規則」?如果這不是答案,我可以看看其他基於模式的選項?

回答

1

您可以使用規範模式,因爲它只是使用包含其他對象的候選類型,即通過擴展ISpecification<Pair<MainType,ExternalType>>來構建對的構建驗證。

如果您不是使用已提供PairTuple類型的語言工作,那麼您當然也必須創建該語言以使用此策略。

如果這不適合你,那麼在模式上構建你自己的變體當然沒關係。他們真的不是設計規則,而是指導。