传递颜色的策略(避免参考？)

Question

我在老化的Windows应用程序中重构代码,我遇到了各种各样的模式,我不确定我喜欢:类有全局颜色变量,如下所示:

private Color myForegroundColor = Color.Azure;
private Color myBackgroundColor = Color.Empty;
// ...etc. 

有很多这些,并且它们被传递给负责设置UI的某些部分的方法.

我认为a Color是一个结构,因此每个颜色都由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);

这是一个很好的解决方案,还是有更好的策略来处理这样的资源？

Answer 1

整件事闻起来像是过早的优化，特别是链接的第 3 部分和第 4 部分，所以......

另一种解决方案是仅删除引用，并Color在需要时复制结构。结构本身并不太大（4 个byte成员和 4 个bool成员），除非您调用每秒更改颜色数百万次的代码，否则所需的时间和内存不是问题。