Can't I just use all static methods?

Question

What's the difference between the two UpdateSubject methods below? I felt using static methods is better if you just want to operate on the entities. In which situations should I go with non-static methods?

public class Subject
{
    public int Id {get; set;}
    public string Name { get; set; }

    public static bool UpdateSubject(Subject subject)
    {
        //Do something and return result
        return true;
    }
    public bool UpdateSubject()
    {
        //Do something on 'this' and return result
        return true;
    }
}

I know I will be getting many kicks from the community for this really annoying question but I could not stop myself asking it.

Does this become impractical when dealing with inheritance?

Update:
Its happening at our work place now. We are working on a 6 month asp.net web application with 5 developers. Our architect decided we use all static methods for all APIs. His reasoning being static methods are light weight and it benefits web applications by keeping server load down.

Answer 1

I'll go with the most obvious problems of static methods with explicit "this" parameters:

1. You lose virtual dispatch and subsequently polymorphism. You can never override that method in a derived class. Of course you can declare a new (static) method in a derived class, but any code that accesses it has to be aware of the entire class hierarchy and do explicit checking and casting, which is precisely what OO is supposed to avoid.

2. Sort of an extension of #1, you can't replace instances of the class with an interface, because interfaces (in most languages) can't declare static methods.

3. The unnecessary verbosity. Which is more readable: Subject.Update(subject) or just subject.Update()?

4. Argument checking. Again depends on the language, but many will compile an implicit check to ensure that the this argument is not null in order to prevent a null reference bug from creating unsafe runtime conditions (kind of a buffer overrun). Not using instance methods, you'd have to add this check explicitly at the beginning of every method.

5. It's confusing. When a normal, reasonable programmer sees a static method, he is naturally going to assume that it doesn't require a valid instance (unless it takes multiple instances, like a compare or equality method, or is expected to be able to operate on null references). Seeing static methods used this way is going to make us do a double or perhaps triple take, and after the 4th or 5th time we are going to be stressed and angry and god help you if we know your home address.

6. It's a form of duplication. What actually happens when you invoke an instance method is that the compiler or runtime looks up the method in the type's method table and invokes it using this as an argument. You are basically re-implementing what the compiler already does. You're violating DRY, repeating the same parameter again and again in different methods when it's not needed.

It's hard to conceive of any good reason to replace instance methods with static methods. Please don't.

Answer 2

You've pretty much described exactly how you do OOP in C, in which only static methods are available, and "this" is a struct pointer. And yes, you can do run time polymorphism in C by specifying a function pointer during construction to be stored as one element of the struct. Instance methods available in other languages are just syntactic sugar that essentially does exactly the same thing under the hood. Some languages, like python, are halfway between, where the "self" parameter is explicitly listed, but special syntax for calling it handles inheritance and polymorphism for you.

Answer 3

The problem with static method comes the moment you need a sub-class.

Static methods cannot be overridden in sub-classes, hence your new classes cannot provide new implementations of the methods, making them less useful.

Answer 4

If you declare a method static, you do not have to instantiate an object from the class (using the new keyword) to execute the method. However, you can't refer to any member variables unless they are also static, in which case those member variables belong to the class, not a specific instantiated object of the class.

Put another way, the static keyword causes a declaration to be part of the class definition, so it becomes a single reference point across all instances of the class (objects instantiated from the class).

It follows, then, that if you want multiple running copies of your class, and you don't want the state (member variables) to be shared among all of your running copies (i.e. each object holds its own unique state), then you cannot declare those member variables static.

In general, you should use static classes and methods only when you are creating utility methods that accept one or more parameters, and return an object of some sort, without any side effects (i.e. changes to state variables in the class)

Answer 5

You're basically defeating the whole point of objects when you do this. There's a good reason we have pretty much shifted from procedural code to object oriented code.

I would NEVER declare a static method that took the class type as a parameter. That just makes the code more complex for no gain.

Answer 6

The reason people argue that 'static methods show bad design' isn't necessarily due to the methods, it's actually static data, implicit or explicit. By implicit I mean ANY state in the program that isn't contained in the return value(s) or parameters. Modifying state in a static function is a throwback to procedural programming. However if the function does not modify state, or delegates state modification to component object functions, it's actually more a functional paradigm than procedural.

If you're not changing state, static methods and classes can have many benefits. It makes it much easier to ensure a method is pure, and thus free of side effects and any errors are fully reproducible. It also ensures that different methods in multiple applications using a shared library can be assured they will get the same results given the same input, making both error tracking and unit testing much easier.

Ultimately there's no difference in practice between oversized objects commonly seen such as 'StateManager' and static or global data. The benefit of static methods used correctly is they can indicate the author's intent to not modify state to later revisers.

Answer 7

Depending on the language and what you are trying to do, the answer may be that there's not a lot of difference, but the static version has a bit more clutter.

As your example syntax suggests Java or C#, I think Thorbjørn Ravn Andersen is right to point out the overriding (with late binding) issue. With a static method, there is no "special" parameter for late binding to be based on, so you can't have late binding.

In effect, a static method is just a function in a module, that module having the same name as the class - it isn't really an OOP method at all.