C# – How do parameters and their usage in methods effect the static/instance design decision

cstaticstatic methods

Just a simple question:

I have read that a class should be made static when it does not modify its instance. So if I have a class which is called Account and it has properties such as Id, Duration, etc and these do not get modified by the class, then this can be made static otherwise it should remain static.

How does this (whether the instance itself, via its properties, mutates) effect the static/instance decision?

Furthermore, if a class takes loads of parameters (say this Account class, sticking to our analogy), but does not modify the instance (so no Account variable changes – nothing like Account.x = y // where y is from another class), I assume this can be still made static? So it's not the parameters which are an issue or where they come from, it's what they do?

If it is a property, the same principles apply as when deciding to make a field static or not (such as if the data the field holds will be expensive to get, then have one field holding it – static – correct me if I am wrong).

I've noticed there are over 100 threads on static methods (this falls into a static method as it is dealing with parameters) on C# and I will read all of these as there are good questions and good answers.

Thanks

Best Answer

It sounds like you're looking to make the class immutable, rather than static?

Here's the definition of a Static Class from C# 3 in a Nutshell: "A class can be marked static, indicating that it must be comprised solely of static members and cannot be subclassed. The System.Console and System.Math classes are good examples of static classes."

In the case of an Account, I assume you want an individual Account instance for each account in your system. So that I don't think you want it to be static.

Related Solutions

C# – String representation of an Enum

Try type-safe-enum pattern.

public sealed class AuthenticationMethod {

    private readonly String name;
    private readonly int value;

    public static readonly AuthenticationMethod FORMS = new AuthenticationMethod (1, "FORMS");
    public static readonly AuthenticationMethod WINDOWSAUTHENTICATION = new AuthenticationMethod (2, "WINDOWS");
    public static readonly AuthenticationMethod SINGLESIGNON = new AuthenticationMethod (3, "SSN");        

    private AuthenticationMethod(int value, String name){
        this.name = name;
        this.value = value;
    }

    public override String ToString(){
        return name;
    }

}

Update Explicit (or implicit) type conversion can be done by

adding static field with mapping
```
private static readonly Dictionary<string, AuthenticationMethod> instance = new Dictionary<string,AuthenticationMethod>();
```
- n.b. In order that the initialisation of the the "enum member" fields doesn't throw a NullReferenceException when calling the instance constructor, be sure to put the Dictionary field before the "enum member" fields in your class. This is because static field initialisers are called in declaration order, and before the static constructor, creating the weird and necessary but confusing situation that the instance constructor can be called before all static fields have been initialised, and before the static constructor is called.
filling this mapping in instance constructor
```
instance[name] = this;
```

and adding user-defined type conversion operator

public static explicit operator AuthenticationMethod(string str)
{
    AuthenticationMethod result;
    if (instance.TryGetValue(str, out result))
        return result;
    else
        throw new InvalidCastException();
}

Java – Why can’t I define a static method in a Java interface

Java 8 permits static interface methods

With Java 8, interfaces can have static methods. They can also have concrete instance methods, but not instance fields.

There are really two questions here:

Why, in the bad old days, couldn't interfaces contain static methods?
Why can't static methods be overridden?

Static methods in interfaces

There was no strong technical reason why interfaces couldn't have had static methods in previous versions. This is summed up nicely by the poster of a duplicate question. Static interface methods were initially considered as a small language change, and then there was an official proposal to add them in Java 7, but it was later dropped due to unforeseen complications.

Finally, Java 8 introduced static interface methods, as well as override-able instance methods with a default implementation. They still can't have instance fields though. These features are part of the lambda expression support, and you can read more about them in Part H of JSR 335.

Overriding static methods

The answer to the second question is a little more complicated.

Static methods are resolvable at compile time. Dynamic dispatch makes sense for instance methods, where the compiler can't determine the concrete type of the object, and, thus, can't resolve the method to invoke. But invoking a static method requires a class, and since that class is known statically—at compile time—dynamic dispatch is unnecessary.

A little background on how instance methods work is necessary to understand what's going on here. I'm sure the actual implementation is quite different, but let me explain my notion of method dispatch, which models observed behavior accurately.

Pretend that each class has a hash table that maps method signatures (name and parameter types) to an actual chunk of code to implement the method. When the virtual machine attempts to invoke a method on an instance, it queries the object for its class and looks up the requested signature in the class's table. If a method body is found, it is invoked. Otherwise, the parent class of the class is obtained, and the lookup is repeated there. This proceeds until the method is found, or there are no more parent classes—which results in a NoSuchMethodError.

If a superclass and a subclass both have an entry in their tables for the same method signature, the sub class's version is encountered first, and the superclass's version is never used—this is an "override".

Now, suppose we skip the object instance and just start with a subclass. The resolution could proceed as above, giving you a sort of "overridable" static method. The resolution can all happen at compile-time, however, since the compiler is starting from a known class, rather than waiting until runtime to query an object of an unspecified type for its class. There is no point in "overriding" a static method since one can always specify the class that contains the desired version.

Constructor "interfaces"

Here's a little more material to address the recent edit to the question.

It sounds like you want to effectively mandate a constructor-like method for each implementation of IXMLizable. Forget about trying to enforce this with an interface for a minute, and pretend that you have some classes that meet this requirement. How would you use it?

class Foo implements IXMLizable<Foo> {
  public static Foo newInstanceFromXML(Element e) { ... }
}

Foo obj = Foo.newInstanceFromXML(e);

Since you have to explicitly name the concrete type Foo when "constructing" the new object, the compiler can verify that it does indeed have the necessary factory method. And if it doesn't, so what? If I can implement an IXMLizable that lacks the "constructor", and I create an instance and pass it to your code, it is an IXMLizable with all the necessary interface.

Construction is part of the implementation, not the interface. Any code that works successfully with the interface doesn't care about the constructor. Any code that cares about the constructor needs to know the concrete type anyway, and the interface can be ignored.