2010-05-26 53 views
1

我遇到了一些困難,並希望得到一些意見。我有這個類,我們稱之爲「汽車」,其中每個實例都有一些單獨的設置(通過屬性),如「顏色」,「HasGearShift」或whatnot(我正在做一個簡單的例子)。這些應該是用戶可定製的,但也應該有默認值。用於管理對象狀態/設置的模式?

所以自然的解決方案是採取所有的「設置」屬性,並將它們分解爲可以序列化/反序列化的單獨的「設置」類。每個Car類還可以繼承Settings類,其中一個設置默認值,並且可以序列化爲用戶自定義的基礎。到現在爲止還挺好。

雖然我覺得我要麼必須忍受這樣的語法遍佈代碼:someCar.Settings.HasGearShift,甚至有一些像這樣的:someCar.Settings.GearBox.CurrentGear但至少沒有冗餘,一切都很好地封裝在Settings類中。

另一種選擇是保留Car類的屬性,並將它們從Settings類複製到類中。然後我可以簡單地寫someCar.HasGearShift。使引用屬性變得更加簡潔,但意味着如果我添加/刪除某些內容,則必須在兩個類中更改設置。

你會選擇哪一個,還是有我錯過的第三個更好的方法?我傾向於第二種選擇,否則在代碼中會出現太多「火車殘骸」:)

回答

6

我想我會選擇兩者之間的東西:使用組合並使用所需的設置製作CarSettings類,並使其可序列化。也許有一個靜態的CarSettings.Default屬性;它定義了默認設置。然後Car可以在構造函數中獲取設置實例,並公開設置的委託屬性,這些屬性需要在外部可見。

public class Car 
{ 
    private CarSettings settings; 

    public Car(CarSettings settings) 
    { 
     settings = settings ?? CarSettings.Default; 
    } 

    public string Color { get {return settings.Color;} } 
} 

public class CarSettings 
{ 
    public string Color {get; private set;} 
    public static CarSettings Default = new CarSettings {Color = "Red"}; 
} 
+0

+1我喜歡這樣 - 雖然它不能解決'編輯設置在兩個類',但它確實使可序列化的'設置'類像DTO – n8wrl 2010-05-26 17:05:08

+0

我認爲你是對的。我有一些反對像傳遞屬性那樣的感覺像是黑客攻擊的東西,但在這種情況下,它可能是兩個惡魔中的更好的,並且使代碼更具可讀性。 – Homde 2010-05-27 00:54:50

0

你可以看看由Visual Studio的Win-窗體設計器中使用現有的設計:

Public Property AlternateItemColors() As Boolean Implements AbstractInterfaces.CoreControls.IVisualList.AlternateItemColors 
    Get 
     Return m_AlternateItemColors 
    End Get 
    Set(ByVal value As Boolean) 
     m_AlternateItemColors = value 
    End Set 
End Property 

Public Overridable Function ShouldSerializeAlternateItemColors() As Boolean 
    If Me.AlternateItemColors = True Then Return False 
    Return True 
End Function 

他們也有使用,比如一些atrributes的

沿東西線; DefaultValue

0

我不確定我在這裏看到問題。看起來你唯一的問題是你不喜歡深層嵌套的屬性。這不是一個真正的問題,您可以輕鬆地只是這樣做在你的代碼的時候,你需要進入設置:

var settings = someCar.Settings; 
settings.Color... 

什麼,我想說的是,你的設計顯得精緻,長語法您擔心不是問題。

+0

問題是,有*很多*的那些參考文件灑在程序周圍,所以看起來相當混亂,並且在所有使用它的地方添加一行這樣的感覺就像它不必要地添加代碼 – Homde 2010-05-27 00:52:18