Another novice question

[gordon]

I aksed a few days ago about static methods and got some good answers that
were really useful.

Now I am not sure if about the use of static on members (variables) and
classes.

Can someone please give me some advice about static classes and members too?

Thanks

Doug

 

[Cor Ligthert [MVP]]

Gordon,

Just as rule for yourself, if you *can* avoid them, than avoid them.

They keep forever the memory occupied and therefore you should use them in
my opinion there were you are sure that you needs them endless times and
don't need more instances of them.

(Be aware that there is other behaviour for ASPNET applications than for
WindowForms applications about static, just because a windowforms is a
client while an ASPNET application is a middle tier)

However (not the later sentence), just my idea.

Cor

 

[Marc Gravell]

I'm not sure I'd put it quite as strongly as Cor... static members do
have their place... but if you have static fields [fields=class level
variables] on a class, then the biggest thing you need to consider is
thread safety - not a trivial subject.

Simple static "helper" functions that don't talk to static fields are
intrinsicly thread-safe, but as soon as fields are involved you need to
be aware that in a non-trivial app different threads may be using the
static class at once, so the impact needs to be understood...

Of course, if you *know* you aren't going to be using threading, then
OK ;-p

Jon Skeet has a very good article on threading - note it goes into many
pages...
http://www.yoda.arachsys.com/csharp/threads/

Marc

 

[Nicholas Paldino [.NET/C# MVP]]

This doesn't make any sense. A static method doesn't keep any memory
occupied beyond the stack that is allocated when the call is made.

However, when the method exits, the memory for the stack is gone as
well.

Static fields are a different story, and yes, they will last as long as
the application domain lasts. However, saying that you shouldn't use them
is a premature optimization, since in reality, they might be pointing to an
object, and the size of the reference is not high. Even if the object is
big, instance members can reference large objects, and live for the life of
an app domain as well, depending on the use.

Also, ASP.NET does not treat static fields any differently. Static
fields live for the life of the app domain, no more, no less. Granted,
ASP.NET recylces app domains, and one has to be aware of that, but static
fields have no say in that, it is the runtime of ASP.NET that determines
that.

In the end, the OP asked about static methods, not static fields.

 

[Cor Ligthert [MVP]]

Did I write what you wrote?

Also, ASP.NET does not treat static fields any differently. Static
fields live for the life of the app domain, no more, no less. Granted,
ASP.NET recylces app domains, and one has to be aware of that, but static
fields have no say in that, it is the runtime of ASP.NET that determines
that.

The behaviour of a windowforms program is different than an ASPNET
application, just because in a windowform program the client is the
application and in a aspnet application that it the genereated
HTML/Javascript page. Therefore the complete application behaves different.
A static method in a ASPNET application acts for the rest the same as in any
other C# application.

Static means fixed. In old non by the OS relocatable programs (C) it means
true fixed to a memory address. In more modern OS it means fixed to the
memory starting point where the program is located. In my idea can there
never been an other description for that otherwise the Static keyword is in
my idea wrong used.

However just my thought,

Cor

 

[Nicholas Paldino [.NET/C# MVP]]

Cor,

Again, you are making a premature optimization. If the design calls for
a static member, then you should use a static member. An extra field
reference isn't going to bring your app tumbling down.

 

[Cor Ligthert [MVP]]

Nick,

It is great, but where is the intention from your current message different
from the first line in the one I started with?

Yours

Again, you are making a premature optimization. If the design calls
for a static member, then you should use a static member. An extra field
reference isn't going to bring your app tumbling down.
Mine

I did nowhere write that you *should* not use them.

Cor

 

[Jon Skeet [C# MVP]]

It is great, but where is the intention from your current message different
from the first line in the one I started with?

Yours

I did nowhere write that you *should* not use them.

But you're suggesting that you should avoid them where possible - in
other words, that it's worth skewing the design in order to avoid them.
I, like Nicholas, disagree with that. If a static member is the natural
design, there's no need to avoid it.

 

[Cor Ligthert [MVP]]

Jon,

Where is a static class or a whatever class a natural design.

I don't know if you believe in the great Englisman Darwin, otherwise have a
look in the Bibble both is about natural design. A static class is never for
me a Natural design as is not any class.

Both you are writing "an extra field reference isn't going to bring your app
tubling down"

I cannot place the context of this message, is this something Nick has
stated in this thread.

You should know that I would be the last one who would write that, therefore
we have had to much discussions about by instance avoiding boxing. From
which I write forever that you should try to avoid that but not put to much
effort in that.

So I am curious in what context you place that sentence?

Cor

 

[Jon Skeet [C# MVP]]

Where is a static class or a whatever class a natural design.

Where utility methods are required, for starters. Besides, you didn't
originaly limit yourself to static classes, but to all static
variables.

At that point, you're preventing patterns such as the singleton pattern
(which does have disadvantages, but is appropriate sometimes).

I don't know if you believe in the great Englisman Darwin, otherwise have a
look in the Bibble both is about natural design. A static class is never for
me a Natural design as is not any class.

What would you do with HttpUtility then, just as an example? All its
members are static, so it effectively could (and should) be a static
class. The fact that it's got a public constructor is a mistake,
basically.

How about the System.Math class?

Both you are writing "an extra field reference isn't going to bring your app
tubling down"

Actually, I never wrote that.

I cannot place the context of this message, is this something Nick has
stated in this thread.

You should know that I would be the last one who would write that, therefore
we have had to much discussions about by instance avoiding boxing. From
which I write forever that you should try to avoid that but not put to much
effort in that.

Again though - where the design naturally uses boxing, it's fine to use
boxing.

So I am curious in what context you place that sentence?

You said to avoid static members where you *can* avoid them. You almost
always *can* avoid them - which means that by your standards, they
should virtually never be used.

Here's an example. Consider the Encoding class and its ASCII property.
That *could* create a new instance of ASCIIEncoding each time, instead
of caching it in a static variable. So one *can* avoid using a static
variable - and according to your logic, one therefore *should* avoid
it. Now, how is creating an instance of ASCIIEncoding every time
Encoding.ASCII is used actually a *good* idea? Do you like having lots
of instances of classes which effectively have no state?

Now, if you didn't actually mean your statement to be as strong as it
was, you shouldn't have made it that way. I can only go by what you've
actually written...

 

[Cor Ligthert [MVP]]

Jon and Nick,

You both read more in what I wrote than I have ever thought about.
Amazing:let me try to give an anology.

In England I try to avoid looking first to the right and than keep my eyes
on the left when I cross a street as I am there. Because I am forever always
the first days a novice in that country. In that perspective should my
advice be seen.

I have seen that newbies take quick the way of modulair programming what in
my eyes using static is. That it is used by an OOP programming language as
C++, VB.Net, VB# or whatever does not change that.

Cor

 

[Jon Skeet [C# MVP]]

You both read more in what I wrote than I have ever thought about.

Then you should have written more carefully. We only expected you to
mean what you said. I don't think that's unreasonable.

Amazing:let me try to give an anology.

In England I try to avoid looking first to the right and than keep my eyes
on the left when I cross a street as I am there. Because I am forever always
the first days a novice in that country. In that perspective should my
advice be seen.

And unless the road has "look right" on, that's entirely reasonable.
The difference is that that is good advice - whereas "avoid static
members whenever you can" is bad advice.

I have seen that newbies take quick the way of modulair programming what in
my eyes using static is. That it is used by an OOP programming language as
C++, VB.Net, VB# or whatever does not change that.

And I would never suggest using static methods exclusively. Don't throw
the baby out with the bathwater though - just because statics shouldn't
be *overused* doesn't mean they shouldn't be used at all.

Similarly, just because static classes shouldn't be overused doesn't
mean they're never part of a good design, as you claimed.

 

[Chris Mullins]

And I would never suggest using static methods exclusively. Don't throw
the baby out with the bathwater though - just because statics shouldn't
be *overused* doesn't mean they shouldn't be used at all.

Similarly, just because static classes shouldn't be overused doesn't
mean they're never part of a good design, as you claimed.

Quite the opposite: I am a huge fan on static classes. Until a way is
devised to indicate a particular method or set of methods is stateless, this
is the best way to do things. As we teach all the server developers:

- State Causes Affinity
- Affinity is the Enemy of Performance
Therefore: Avoid State.

One of these days I'm going to write the StatelessMethodAttribute, and build
an FxCop rule to check for member / property access withing the method.

 

[Ben newsam]

In England I try to avoid looking first to the right and than keep my eyes
on the left when I cross a street as I am there.

Bad idea. Although we drive on the left, which you may find confusing,
it is a Good Plan to look *both* ways, lol.

 

[Ben newsam]

Where is a static class or a whatever class a natural design.

Well... I wrote a class to access the Registry, inserting a default
value if the key in question was not found. To me, that would always
be a static class, as there is never a need to instantiate it. It just
does stuff, and any data it contains is always the same.

 

[Cor Ligthert [MVP]]

This message does not need any answer, to rude and to much beside any
reasonable truth.

Just for those who read it in future.

Cor

 

[Jon Skeet [C# MVP]]

This message does not need any answer, to rude and to much beside any
reasonable truth.

Just for those who read it in future.

It's too rude to expect you to mean what you say? I don't see how. I
think I've given pretty straightforward reasons why I disagree with
you.

If you truly believe that static classes and static variables are never
part of a good design, stick up for that belief and debate it. If you
don't truly believe it, then retract your previous statement.

 

[Jon Skeet [C# MVP]]

Quite the opposite: I am a huge fan on static classes. Until a way is
devised to indicate a particular method or set of methods is stateless, this
is the best way to do things. As we teach all the server developers:

- State Causes Affinity
- Affinity is the Enemy of Performance
Therefore: Avoid State.

One of these days I'm going to write the StatelessMethodAttribute, and build
an FxCop rule to check for member / property access withing the method.

Well, there's an alternative I'm becoming quite a fan of - inversion of
control with something like the Spring framework, creating instances
which *after creation* don't change state.

That way you can still configure components (which makes life really
handy for unit testing) and have multiple instances doing different
jobs (eg validating text using different regular expressions) but still
keep the performance of stateless classes by ensuring that the state
won't change. So long as all the threads using the components aren't
created until after the components have been created, there should be
no thread safety issues (or at least, no more than with static
classes). Is this a pattern you've tried and found wanting?

 

[Chris Mullins]

Well, there's an alternative I'm becoming quite a fan of - inversion of
control with something like the Spring framework, creating instances
which *after creation* don't change state.

That way you can still configure components (which makes life really
handy for unit testing) and have multiple instances doing different
jobs (eg validating text using different regular expressions) but still
keep the performance of stateless classes by ensuring that the state
won't change. So long as all the threads using the components aren't
created until after the components have been created, there should be
no thread safety issues (or at least, no more than with static
classes). Is this a pattern you've tried and found wanting?

I have gone quite a bit down the immutable class route in more recent
months. More and more of my objects are constructed, then never changed.
When a change happens, the entire object is replaced with a new one. The
ReadOnly keyword in C# has helped with this. This has been a big help in
terms on elimination of contention in the general case.

I'll have to take a look at that pattern and framework. Thanks for the
pointer.

 

[Cor Ligthert [MVP]]

Jon Skeet.

If you truly believe that static classes and static variables are never
part of a good design, stick up for that belief and debate it. If you
don't truly believe it, then retract your previous statement.

This is not even misquouting, this is putting on this board (Internet)
something I never wrote giving people the idea that I did.

Maybe it is in your opinion not rude, I will not place on Interenet what my
opinion is about this kind of behaviour.

Cor