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'，也可以防止复制结构。 –