c# vb: when they say static classes should not have state

when they say static classes should n开发者_JAVA百科ot have state/side effects does that mean:

    static void F(Human h)
    {
        h.Name = "asd";
    }

is violating it?

Edit:

i have a private variable now called p which is an integer. It's never read at all throughout the entire program, so it can't affect any program flow.

is this violating "no side effects"?:

int p;
static void F(Human h)
    {
        p=123;
        h.Name = "asd";
    }

the input and output is still always the same in this case..

---

When you say "they", who are you refering to?

Anyways, moving on. A method such as what you presented is completely fine - if that's what you want it to do, then OK. No worries.

Similarly, it is completely valid for a static class to have some static state. Again, it could be that you would need that at some point.

The real thing to watch out for is something like

static class A
{
    private static int x = InitX();

    static A()
    {
        Console.WriteLine("A()");
    }

    private static int InitX()
    {
        Console.out.WriteLine("InitX()");
        return 0;
    }
    ...
}

If you use something along these lines, then you could easily be confused about when the static constructor is called and when InitX() is called. If you had some side effects / state changing that occurs like in this example, then that would be bad practice.

But as far as your actual question goes, those kind of state changes and side effects are fine.

Edit

Looking at your second example, and taking the rule precisely as it is stated, then, yes, you are in violation of it.

But...

Don't let that rule necessarily stop you from things like this. It can be very useful in some cases, e.g. when a method does intensive calculation, memoization is an easy way to reduce performance cost. While memoization technically has state and side-effects, the output is always the same for every input, which is the really important .

---

Side effects of a static member mean that it change the value of some other members in its container class. The static member in your case does not effect other members of its class and it is not violating the sentence you have mentioned.

---

EDIT

In the second example you've added by editting your question you are violating it.

---

It is perfectly acceptable for methods of a static class to change the state of objects that are passed to them. Indeed, that is the primary use for non-function static methods (since a non-function method which doesn't change the state of something would be pretty useless).

The pattern to be avoided is having a static class where methods have side-effects that are not limited to the passed-in objects or objects referenced by them. Suppose, for example, one had an embroidery-plotting class which had functions to select an embroidery module, and to scale, translate, or rotate future graphic operations. If multiple routines expect to do some drawing, it could be difficult to prevent device-selections or transformations done by one routine from affecting other routines. There are two common ways to resolve this problem:

1. Have all the static graphic routines accept a parameter which will hold a handle to the current device and world transform.
2. Have a non-static class which holds a device handle and world transform, and have it expose a full set of graphic methods.

In many cases, the best solution will be to have a class which uses the second approach for its external interface, but possibly uses the first method internally. The first approach is somewhat better with regard to the Single Responsibility Principle, but from an external calling standpoint, using class methods is often nicer than using static ones.