古くなったWindowsアプリケーションでコードをリファクタリングしていますが、ある種のパターンに出くわしましたが、気に入っているかどうかはわかりません。クラスには、次のようなグローバルカラー変数があります。
private Color myForegroundColor = Color.Azure;
private Color myBackgroundColor = Color.Empty;
// ...etc.
これらはたくさんあり、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);
これは良い解決策ですか、それともこのようなリソースを処理するためのより良い戦略がありますか？