重構基於許多參數進行計算的類的最佳設計模式

Question

我正在重構一組類，如下所示，它執行一些價格計算。計算是基於許多參數完成的。 的代碼是：

public interface IParcel { 
    int SourceCode { get; set; } 
    int DestinationCode { get; set; } 
    int weight{get;set;} 
    decimal CalculatePrice(); 
} 

public abstract class GeneralParcel : IParcel { 
    //implementation of inteface properties 
    //these properties set with in SourceCode & DestinationCode 
    //and are used in CalculatePrice() inside classes that inherit from GeneralParcel 
    protected SourceProvinceCode{get; protected set;} 
    protected DestinationProvinceCode{get;protected set;} 

    //private variables we need for calculations 
    private static ReadOnlyDictionary<int, List<int>> _States_neighboureness; 
    private static ReadOnlyCollection<City> _Citieslist; 
    private static ReadOnlyCollection<Province> _Provinceslist; 

    protected ReadOnlyCollection<City> Citieslist {get { return _Citieslist; }} 

    protected ReadOnlyCollection<Province> ProvincesList {get { return _Provinceslist; }} 

    protected ReadOnlyDictionary<int, List<int>> StatesNeighboureness {get {return _States_neighboureness; }} 

    //constructor code that initializes the static variables 

    //implementation is in concrete classes 
    public abstract decimal CalculatePrice(); 
} 

public ExpressParcel : GeneralParcel { 
    public decimal CalculatePrice() { 
     //use of those three static variables in calculations 
     // plus other properties & parameters 
     // for calculating prices 
    } 
} 


public SpecialParcel : GeneralParcel { 
    public decimal CalculatePrice() { 
     //use of those three static variables in calculations 
     // plus other properties & parameters 
     // for calculating prices 
    } 
} 

眼下，代碼使用「策略模式」有效。

我的問題是，那三個靜態屬性，真的不是parcel對象的一部分，它們只需要進行價格計算，那麼建議哪個設計模式或者wrap（重構）呢？

是否有另一個接口，如下所需（&然後將它們內部的靜態屬性包裹起來？甚至使得該靜態類，因爲它基本上只是一些計算），那麼如何將它連接到IParcel？ 這樣做，如何實現CalculatePrice()在SpecialParcel & ExpressParcel類？

public interface IPriceCalculator { 
    decimal CalculatePrice(); 
} 

編輯：以上只是所有系統的大畫面，也有在評論，我們鐵餅關於他們其他的考慮，我在這裏他們寫一遍清理的東西。

對於所有ParcelType，有BulkDiscount。當客戶發送10個以上的包裹（或任何閾值）時，發送大量帖子，當一個客戶發送超過10個包裹到一個唯一的目的地（只有一個接收者）時，也有特別折扣。現在這種類型的折扣在每個宗地類型的CalculatePrice()中進行管理。即使7Kg以下的包裹也有折扣。

也現在有3 parceltype，我只在這裏顯示2。但我們需要在將來添加其他類型（TNT & DHL支持）。每種類型都有很多服務，客戶可以選擇並付費。例如 ，sms service或email service &等等。

Answer 1

IPriceCalculator將是單一責任原則的最佳實踐。

但將方法的簽名更改爲decimal CalculatePrice(IParcel parcel); 該方法調用IParcel的CalculatePrice（）方法以獲取每個宗地的基價。

Answer 2

您爲給定宗地計算價格的方式是不應該屬於數據對象的責任。

鑑於你告訴我，這裏是我將如何實現，嘗試並考慮未來的考慮：

public interface IParcel { 
    int SourceCode { get; set; } 
    int DesinationCode { get; set; } 
    int Weight { get; set; } 
} 

public class PricingCondition { 
    //some conditions that you care about for calculations, maybe the amount of bulk or the date of the sale 
    //might possibly be just an enum depending on complexity 
} 

public static class PricingConditions { 
    public static readonly PricingCondition FourthOfJulyPricingCondition = new PricingCondition(); 
    public static readonly PricingCondition BulkOrderPricingCondition = new PricingCondition(); 
    //these could alternatively come from a database depending on your requirements 
} 

public interface IParcelBasePriceLookupService { 
    decimal GetBasePrice(IParcel parcel); 
    //probably some sort of caching 
} 

public class ParcelPriceCalculator { 
    IParcelBasePriceLookupService _basePriceLookupService; 

    decimal CalculatePrice(IParcel parcel, IEnumerable<PricingCondition> pricingConditions = new List<PricingCondition>()) { 
     //do some stuff 
    } 
    decimal CalculatePrice(IEnumerable<IParcel> parcels, IEnumerable<PricingCondition> pricingConditions = new List<PricingCondition>()) { 
     //do some stuff, probably a loop calling the first method 
    } 
} 

Answer 3

像你說的，那些靜態屬性並不是真正的GeneralParcel類的一部分。將它們移動到靜態的「ListsOfThings」類。

然後你可以使用代碼ListsOfThings.ProvincesList等

Answer 4

就個人而言，雖然其他人可能會說包裹不應該知道如何計算自己的運費，但我不同意。您的設計已經通過三種不同的計算標識出有三種不同的計算，所以對於我的（天真的）眼睛來說，物體應該有一種方法是完全合適的，例如， CalculatePrice()。

如果你真的想要走那條路，那麼你需要的IParcelPriceCalculator兩個實現（或者無論你怎麼稱呼它），在GeneralParcel一個抽象的工廠方法來創建具體ExpressParcelPriceCalculator或SpecialParcelPriceCalculator類。個人而言，我認爲這是一種矯枉過正的情況，至少由於代碼將與每個GeneralParcel實現緊密耦合。

我會然而考慮作出的City和ProvinceCity和Province公共靜態屬性靜態集合分別。這只是更整潔，而且如果我維護代碼，它就是我期望找到它們的地方。 StatesNeighbourliness可能應該進入省，否則它甚至可能證明自己的階級是合理的。

Answer 5

我提供的建議將取決於你如何去生成和使用Parcel多形體。我的意思是，我們看不到用什麼標準來確定某些東西是「快速」還是「特殊」，以及這些標準是否與包裹本身的屬性或某些外部因素有關。儘管如此，我認爲你的直覺是將價格計算與Parcel對象本身分開的好方法。正如kmkemp指出的那樣，包裹不應該根據包裹的類型來計算包裹的價格。一個包裹是一個數據傳輸/ POCO類型的對象，至少如您給它的重量，來源等所示。

但是，我不清楚你爲什麼使用這些接口。不要誤會我的意思 - 接口對於解耦和可測試性來說很好，但爲什麼除了抽象基類和抽象方法以外，還有一個parcel接口。就個人而言，事情只是我的資料，我應該這樣做：

public class Parcel 
{ 
    int SourceCode { get; set; } 
    int DestinationCode { get; set; } 
    int weight { get; set; } 
} 

public abstract class GeneralCalculator 
{ 
    //Statics go here, or you can inject them as instance variables 
    //and they make sense here, since this is presumably data for price calculation 
    protected static ReadOnlyDictionary<int, List<int>> _States_neighboureness; 
    protected static ReadOnlyCollection<City> _Citieslist; 
    protected static ReadOnlyCollection<Province> _Provinceslist; 
    //.... etc 

    public abstract Decimal CalculatePrice(Parcel parcel); 
} 

public class ExpressCalculator : GeneralCalculator 
{ 
    public override decimal CalculatePrice(Parcel parcel) 
    { 
     return 0.0M; 
    } 
} 

public class SpecialCalculator : GeneralCalculator 
{ 
    public override decimal CalculatePrice(Parcel parcel) 
    { 
     return 0.0M; 
    } 
} 

但同樣，我不知道怎麼包裹實際上正在處理中。您可能需要對此概念進行某種修改，具體取決於您如何生成並處理這些包裹。例如，如果包裹的種類取決於包裹的屬性值，則可能需要定義一個工廠方法或類，它接受一個包裹並返回計算器的相應實例。

但是，無論如何修改它，我一定會爲您考慮將計算其價格的計劃的定義從計劃中解耦出來而投下我的票。數據存儲和數據處理是不同的問題。我也不會贊成在某個包含全局設置的靜態類，但這是我個人的喜好 - 這種事情很容易獲得一個setter併成爲一個全球變量。