Static Methods

  • Thread starter Thread starter Jim Heavey
  • Start date Start date
J

Jim Heavey

Hello, hoping you can clear up a little bit of confusion that I have on
creating/using static methods.

I want to create a class which hold all my "Utility Methods" for windows
forms. So I created a new project and added that project to my existing
project. The project "type" I selected was a "Class Library". What
this a correct choice.

So if I want to create "Static" methods, does the class itself have to
be static? There is no real reason to instatiate the class, so I am
guessing that I should make the class static. When I attempt to do
this, it tells me the modifier is not valid for this item. Have I got
the wrong format, or the wrong idea? Here is my code...

namespace WindowFormsUtilities
{
/// <summary>
/// Summary description for Class1.
/// </summary>
public static class WindFormUtilities
{
public static WindFormUtilities()
{
//
// TODO: Add constructor logic here
//
}
public static bool SetComboBoxSelectionError(ComboBox cbo,
ErrorProvider err)
{
}

private bool[] SetComboBoxSelectionError (ComboBox[] cbo,
ErrorProvider err)
{
}

}
}
 
Just make a regular class and make the methods (only) static. All data used
int her methods will also have to be declared static.
 
A class Library project is the correct project type, and no, you can't
create a static class. The general rule if you are creating a class that
has all static methods is to make it sealed, since deriving from the class
wouldn't gain anything, and to declare a private default constructor so no
one can create an instance of you class.
 
Jim,
So if I want to create "Static" methods, does the class itself have to
be static? There is no real reason to instatiate the class, so I am
guessing that I should make the class static. When I attempt to do
this, it tells me the modifier is not valid for this item. Have I got
the wrong format, or the wrong idea? Here is my code...
Click to expand...

Unless you're using the Whidbey version of C#, there's no such thing
as a static class. You can make it abstract or add a private
constructor to prevent it from being instantiated.



Mattias
 
So if I want to create "Static" methods, does the class itself have to
be static? There is no real reason to instatiate the class, so I am
guessing that I should make the class static. When I attempt to do
this, it tells me the modifier is not valid for this item. Have I got
the wrong format, or the wrong idea? Here is my code...
Click to expand...

I generally make classes with only static members, sealed with a private
constructor. Similar to:

public sealed class MyUtilityClass
{
private MyUtilityClass() // Prevent direct instantiation.
{
}
}

The 'sealed' property prevents someone from inheriting the class, the
private constructor prevents someone from creating an instance of the class
:) From reading your mail I think 'sealed' is basically the equivalent of
what you were expecting a 'static' class to be.

n!
 
n! said:
I generally make classes with only static members, sealed with a private
constructor. Similar to:

public sealed class MyUtilityClass
{
private MyUtilityClass() // Prevent direct instantiation.
{
}
}

The 'sealed' property prevents someone from inheriting the class, the
private constructor prevents someone from creating an instance of the class
:) From reading your mail I think 'sealed' is basically the equivalent of
what you were expecting a 'static' class to be.
Click to expand...

There's no real need to make the class sealed as well as only having a
private constructor - just the fact that its only constructor is
private means that you can't inherit from it.
 
Then why does the compiler permit this combination? Isnt this like havint a
string as a const and static? You cant because it makes no sense, just as
what you say , it makes no sense.
 
Then why does the compiler permit this combination? Isnt this like havint a
string as a const and static? You cant because it makes no sense, just as
what you say , it makes no sense.
Click to expand...

I think there's a difference in the level of logical connection there.
It's not that there's anything *syntactically* redundant about there
being a sealed class with only a private constructor, it's only
*semantically* redundant.

It would be reasonable of the compiler to complain, but I don't think
it's particularly necessary for it to do so.

(There's also the fact that the two will end up in different IL - a
class with only private constructors is *effectively* sealed, it isn't
*actually* sealed.)
 
There's no real need to make the class sealed as well as only having a
private constructor - just the fact that its only constructor is
private means that you can't inherit from it.
Click to expand...

That's true, though the private constructor is there to prevent creation of
a class instance rather than prevent inheritance (even though it effectively
does that job as well), and the compile error is more meaningful when trying
to inherit a sealed class rather than a class with private constructors. :)

n!
 
Back
Top