<snip>

Taking the most "right by design" path is almost *always* the right
thing to do. Before you ever start bending the design out of shape,
measure the performance and see whether or not:
a) you actually have a problem
b) the change helps significantly

I can't remember the last time this was actually the case for me.

Jon

The C# compiler probably shouldn't do this, but the JIT compiler might,
yes. Not in debug mode though - you might print out "this" from the
debugger :)

<snip>

Well, does Pow depend in any way upon the instance of a Math? What
distinguishes one instance from another? Is there any sense in which
polymorphism is relevant? These are the questions to ask - the answer
usually comes from there.

There's nothing wrong with it, except that everyone is forced to instantiate
a Math object that has no state -- it's really not much of an object at all.
 There's literally nothing to distinguish two Math objects from each other
-- they might as well all *be* one object. So it's natural to make Math's
methods static, so that it effectively *is* one object. Saves typing and
possible initialization errors.

Now, compare this to the Random class, which is very similar to Math in
being a facility class. Random *does* have state -- the state of the random
number generator, on which the next generated number depends. If we made the
methods instance methods, we'd effectively force every client to share the
same Random state, which limits the usefulness of the class -- it makes it
impossible to generate a known sequence of numbers by seeding the generator,
for example. So Random has instances, even though most clients will reuse
the same instance as much as possible.

The vast majority of objects are distinct, having their own state, which
their methods modify. This is why the vast majority of methods are instance
methods. Static methods are used when there is no need for object state,
which occurs in a variety of circumstances:

- Facility classes without instances, like Math. Forcing the use of an
instance would have no benefits.

- Methods that construct or return object instances. A constructor can be
seen as a special kind of static method. More complex construction scenarios
may use a static factory method rather than a constructor, to enable
caching, for example. Encoding.GetEncoding() and XmlWriter.Create() are good
examples.

- Methods that operate on state shared between all instances of a class. The
canonical example is a method that returns a count of instances or that
increments an auto-generated ID, although neither has much practical
relevance. In .NET, these usually end up as properties rather than methods.
Methods that actually modify shared state often do so as part of a
construction pattern (see previous item) and are usually better off as
instance methods of a separate Factory class, because it gets hard to
understand quickly -- your class effectively becomes its own object.

- Methods that, by happenstance, do not need object state. For example, if
you decompose a complex method into separate functions, it may be that a
function does not operate on any object state, but only on its arguments. In
this case, making the function static may serve as an aid in maintaining and
debugging: you know that that method does not modify object state. This is
an implementation artifact, however, and should be reserved for private
methods (and they could be made instance methods whenever warranted).

This is not necessarily an exhaustive list, just what I can think of right
now. Like I said, instance methods are much more common, and you almost
never have to worry "do I need to make this method an instance method or a
static method" because it's usually dictated by purpose.