5
我在老化的Windows應用程序中重構代碼，並且遇到了各種各樣的模式，我並不確定自己喜歡：一個類具有全局顏色變量，如下所示：周圍的顏色傳遞策略（避免參考？）
private Color myForegroundColor = Color.Azure;
private Color myBackgroundColor = Color.Empty;
// ...etc.
還有一堆的這些，和他們正在被裁判各地傳遞給負責建立用戶界面的某些部分的方法。
我收集到一個Color是一個結構體，並且每個顏色都由ref傳遞，以避免每次調用方法時都創建新的副本。 IE是這樣的：
// Avoid creating a copy of myForgroundColor inside SetUpButton():
MyHelperClass.SetUpButton(ref myForegroundColor);
我不禁感慨，這個用法ref整個類和相關類是壞的。這感覺就像一個「code smell」，雖然我真的不能指責爲什麼。
我見過一對夫婦類似問題的帖子，包含「使用含有顏色的類，然後將其作爲一個值類型通過了」建議，但它並不完全清楚怎麼會是最好的做這個。
我想什麼做的是創建一個類似於下面的內容：
public class ColorContainer
{
public UiSettingsContainer()
{
MyColor = Color.Black;
MyNextColor = Color.Blue;
// ..etc...
}
public Color MyColor { get; private set; }
// ...etc....
}
這會讓我保持顏色的控制，但對記憶的影響是一點我不清楚;如果我創建了這個類的一個實例並將其傳遞給需要關於包含顏色的信息的方法，那麼只要實現方法使用該方法就不會創建color（它是一個結構體）的副本嗎？
上午我在假設該代碼將創建一個新的副本，因此不太有效糾正...
// Assumption: This creates a new copy of color in memory.
public void SetSomeColor(Color col){
someComponent.color = col;
}
// Calling it:
SetSomeColor(myColorContainerInstance.MyColor);
...比這個代碼，這隻會利用現有的結構嗎？ ：
// Question: Does this avoid creating a new copy of MyColor in memory?
public void SetSomeColor(ColorContainer container){
someComponent.color = container.MyColor;
}
// Calling it:
SetSomeColor(myColorContainerInstance);
我目前傾向朝着類似於以下，這是我收集的顏色在一個單獨的類和重組代碼位的解決方案，但繼續使用ref。在這種情況下，然而，MyColor將不得不在ColorContainer公共領域，這意味着我將有超過誰可以將它設置較少的控制值：
// Assumption: This creates a new copy of color in memory.
public void SetSomeColor(ref Color col){
someComponent.color = col;
}
// Calling it:
SetSomeColor(ref myColorContainerInstance.MyColor);
這是一個很好的解決方案，還是有更好的戰略處理這樣的資源？
你不能只是讓這些用戶設置一個靜態/全局的傢伙？ –
爲什麼你想避免複製'顏色'對象？ – delnan
如果'SetSomeColor'沒有標記爲'virtual'，那麼JIT就有很好的機會將方法內聯，即使參數沒有標記爲'ref'，也可以防止複製結構。 –