我在一个老化的 Windows 应用程序中重构代码，我遇到了一种模式，我不确定我是否喜欢：一个类有全局颜色变量，如下所示：
private Color myForegroundColor = Color.Azure;
private Color myBackgroundColor = Color.Empty;
// ...etc.
其中有很多，它们通过 ref 传递给负责设置 UI 某些部分的方法。
我认为 aColor是一个结构，因此每种颜色都由 ref 传递，以避免在每次调用方法时创建它的新副本。IE 类似：
// Avoid creating a copy of myForgroundColor inside SetUpButton():
MyHelperClass.SetUpButton(ref myForegroundColor);
我不禁感到ref整个班级和相关班级的这种用法很糟糕。感觉就像是一种“代码味道”，尽管我无法真正说出原因。
我看过一些关于类似问题的帖子，其中建议“使用包含颜色的类，然后将其作为值类型传递”，但目前尚不完全清楚如何最好地做到这一点。
我想做的是创建类似于以下内容的内容：
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);
这是一个好的解决方案，还是有更好的策略来处理这样的资源？