Earlier quoted context omitted.
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 ex…
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.
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.