I created a static class with a private static member inside of it. That private static member is accessible to all of my static class methods.
This happened while I wasn't really paying attention, but then I realized what I had done, and that - interestingly enough - it seems to be working fine in my application. Nonetheless, it seemed like a silly thing to do (coming from C++), so I have been searching around trying to find more info on whether this is really supposed to be possible and/or if it is considered good or bad practice, but I haven't really been able to find anything at all about creating private static members inside a static class in C#.
It almost seems like static methods inside my static class have an implicit "this" variable (since I'm also able to call other methods without fully qualifying them with the class name), which feels a be peculiar to me.
I was hoping some of you might have some thoughts about whether this is a good idea or not, and why C# makes this possible at all.
The class:
public static class ControlHighlighter
{
private static Panel highlightPanel = null;
public static void Highlight(Control control = null, int thickness = 1)
{
RemoveHighlight();
if (control != null)
{
if (control.Parent != null)
{
highlightPanel = new Panel();
control.Parent.Controls.Add(highlightPanel);
highlightPanel.Location = new Point(control.Location.X - thickness,
control.Location.Y - thickness);
highlightPanel.Size = new Size(control.Size.Width + (2 * thickness),
control.Size.Height + (2 * thickness));
highlightPanel.SendToBack();
highlightPanel.BackColor = SystemColors.Highlight;
}
}
}
public static void RemoveHighlight()
{
if (highlightPanel != null)
{
highlightPanel.Dispose();
highlightPanel = null;
}
}
}
In general, there's nothing wrong with having private static members in static classes (or even in non-static classes). They do pose some potential problems, though: when your application is multithreaded, these static members are shared across all threads so you have to apply locking around them.
Since you never know if you need to make your application multithreaded, it's best to keep the number of static variables to a minimum - all static variables shared between threads must be protected through locks or other synchronization primitives. It's far easier to do this kind of work ahead of time than patching problems later on.
However, in your specific example, you're putting a UI control in a static variable - this is something I'd definitely advise against. UI controls live on the UI thread and must be properly invoked when called from a different thread. Threading issues aside, putting a control in a static variable is a recipe for trouble - the static variable requires careful bookeeping to clean up - if the form hosting the control goes away, the static reference will still keep it in memory (because the control cannot go away). This can lead to all kinds of hard-to-find problems.
If you're not familiar with static in C#, I recommend reading MSDN for more detail.
この記事はインターネットから収集されたものであり、転載の際にはソースを示してください。
侵害の場合は、連絡してください[email protected]
コメントを追加