Hi,

This post is partly inspired by Milop's recent post here, "Sharing
Data," where there was some mention of the use of static variables or
objects, but I feel the issue I want to raise is too OT to post on
that thread.

As a programmer I am well aware of the value of encapsulation, and the
dangers of "global" variables and objects. I'm also aware of
techniques for "injection" of references as needed into classes/
objects created at run-time.

However, I seem to come across many cases where there is clearly one-
and-only-one object or piece of data, or one set of methods, that
needs to be accessed by, for example, a host of UserControls, or a
bunch of "child" forms. I'm not really into "design patterns," but I
guess you could call that a "singleton pattern."

I seem to have no problem defining a static class in WinForms (C#),
and implementing something like public static dictionaries, methods,
etc.

I personally like the separating out of functionality from the "main
form" that comes from using one or more static classes to hold
logically related data sets or groups of functions.

I have experimented, for fun, in taking a WinForm app and going into
the "main form" program.cs file and changing the constructor like so :

            Application.EnableVisualStyles();
            Application.SetCompatibleTextRenderingDefault(false);

            // formController is a public static class ... does not
inherit from Form ...
            // its 'makeNewForm method creates a new Form, sets its
title from the
            // string argument supplied, and make it visible via 'Show
            formController.makeNewForm("the first form");

            Application.Run();

so that it invokes a method in a Static class to create the "main
form" (of course you must then implement a way to make sure the
Application is closed when your final form open is closed which is
simple). To me I find such a technique useful if I have an app design
where I want multiple windows each one of which is an "equal" : i.e.,
no "main form."

I know such solutions are not appropriate for multi-user scenarios,
etc.

But, I am curious to know how you might view such use of static
classes.

thanks, Bill

uncleSally <therealunclesa***@gmail.com> wrote in news:d1b9fb28-f4a7-4654-
9906-74f979c05***@q14g2000vbn.googlegroups.com:

Overall, I use static classes for helper methods, which are more efficient
when loaded into memory once. Outside of this arena, I would have to have a
good case for a static method/class, as there are other issues that can
arise with static classes/methods that are not worth the small benefit of a
one time load into memory.

As for the scenario you are talking about, I see nothing against it off
hand, except it makes your code harder to test. If you have a clean
separation of UI and code, this might not be such a bad thing. But, I have
not really perused the idea deeply, so it is questionable whether or not
someone else can knock huge holes in the idea.


Show quoteHide quote

Gregory A. Beamer wrote :

Hi Gregory,

Thanks for your ocmments ! I visited your blog site, and was
interested to see that you used static methods exclusively (within a
Public scoped non-static class) in your Directory Copy example :
http://gregorybeamer.spaces.live.com/blog/cns!B036196EAF9B34A8!1158.entry

From my perspective, which is probably very limited compared to your
wide experience, I find moving the business of "main" Form creation
out of the "Program.cs" class is a step towards the separation of UI
and code. And, of course, Program.cs, is always defined as a static
class by VS : ... mmm ... if it's good enough for MS and VS, it's good
enough for moi ... ? In my head it's a step toward MVC type
architecture (but I'm not making any "religious" claims here, just
putting forward ideas which I anticipate may change).

The issue you raise about testing when using static classes is one I
am just not equipped to fully fathom at this point, but I would like
to learn more.

best wishes, Bill

uncleSally <therealunclesa***@gmail.com> wrote in
I have been called out for breaking my own rule. LOL

The example in the blog entry is isolated to a single thread, as it is a
copy routine. To be honest, I was being lazy here and avoiding the
instantiation of a class, but it should not matter in this case, as the
app is a single threaded utility class. There is some recursion, which
will reuse the static method, but that is still not an issue, as
everything is running in a single thread.

But, if I were wrapping this with tests, I would have done it as a
class, as it is proper form. I originally started this as a Console app,
which has a static main method.

One thing you should consider when deciding static or not is whether or
not it is a utility app, as this one is, or an app that will be used on
a site, or as part of server code that will run with numerous users.

I actually have some examples of a pass through data layer that are
static, but I am not sure I would opt for that implementation in a
scalable system.

I will have to be a bit more careful of my examples on the blog,
however, as someone who needs a highly scalable system might end up
using static methods on data access, which could be problematic on a
highly scalable system.

One reason people state for using static methods is only loading once
into memory, but it is not as big of a problem, as .NET garbage
collects. The thought, from someone coming from a COM world, is memory
usage is bad, but .NET uses memory differently than COM. A growing
footprint in COM generally means a badly designed app; it is normal in
..NET, as the CLR garbage collects when it needs memory and does not do a
lot out of that scenario.

One thing they found when designing .NET is filled garbage memory does
not impact the system that much. Whether the memory is cleared out or
held generally impacts you most when you have a lot of apps that need
memory, and the CLR is fairly good at cleaning out based on need without
impacting performance much. I thought it was stupid when I first read
it, but Jeffrey Richter has a great explanation of why and how it works
in his book. After reading his explanation, I had an AHA moment.

One temptation in .NET is to try to control the garbage collector (I
know this is OT in this thread). It is a temptation best left when you
find you have a garbage collection problem (very rare) as you are more
likely to screw up the system.

One other temptation is to try to speed things up with structs instead
of classes, as they run on the stack for the program rather than the
heap (general memory). The first time you play with this on a large app
and run out of stack space you are cured of this temptation.

Show quoteHide quote

Design Time Controls
Cannot use Mustinherit in a base form
object properties presentation
System.Windows.Forms.Control.Handle==HWND?
Project consisting of multiple projects
Saving and retrieving WinForm template info
Read From Application Config File In Class Library
Validating Event Bug
Win forms designer - controlling the designer code generation
What control did Microsoft Use?