[MichaelGG]

I find the opposition to static classes odd. Unless you need the data encapsulation of an object, why force people to create an object to call functions? I find too much C# code loves creating objects for no real purpose other than that's how it works.

For SO, if we guess they max out around 2000 req/sec, then if a bunch of objects are being allocated for each request, there could be added GC pressure. From my own experience developing much higher-scale managed code, allocating objects is a real pain and people will take a lot of effort to avoid it.

[Griever]

I think the real issue (although it doesn't seem to be an issue for SO) is testability. AFAIK, static classes cannot be mocked, and you are pretty much boxing yourself into only doing integration tests for everything. Not necessarily a bad way to go, just lots more setup per test.

[MrBuddyCasino]

Yep, that used to be one of the main reasons to have DI in Java. But now that everything (even static methods) can be mocked, that reason is no longer valid. Is this not possible in .NET?

[mattmanser]

It completely depends if you do this:

    public static decimal DiscountValue(Order order)

Or this:

    public static decimal DiscountValue(decimal orderValue, decimal orderDiscount)

Or even this, which would farm the work out to SQL:

    public static decimal DiscountValue(int orderId)

The first would require a mock, the 2nd wouldn't and the third isn't unit testable.

It's a bit of a contrived example, as you're more likely to do the third method if you're trying to get some sort of summary data about an order out which would mean you don't really need/want to load the whole order object.

[tjdetwiler]

A singleton object doesn't need to be re-allocated.

[ygra]

Static classes are an easy way of implementing the Singleton pattern in C# ...

[guiomie]

A singleton can implement interfaces, static classes cant.