20

Having spent a bit of time learning about functional programming, it's becoming more and more natural for me to want to work with static methods that don't perform any mutation.

Are there any reasons why I should curb this instinct?

Khanzor
  • 4,830
  • 3
  • 25
  • 41
  • I've found myself leaning this way due to the amount of concurrent/parallel programming I've been doing. Would be interested to hear other people's opinions. +1, interesting question. – spender Feb 07 '11 at 23:04
  • 1
    I've felt this too and have receive strange looks from colleagues when suggesting that methods be refactored into static function calls leaving just a simple script of state mutating logic in the member methods. I say run with it. – Paul Ruane Feb 07 '11 at 23:05
  • 1
    Can you define 'don't perform any mutation'? – CRice Feb 07 '11 at 23:10
  • 1
    @CRice: [pure](http://en.wikipedia.org/wiki/Pure_function). – Paul Ruane Feb 07 '11 at 23:13
  • @CRice - sure, by not performing any mutation I mean that I'll deep-copy an object and return it if it is the subject of the method I'm calling. – Khanzor Feb 08 '11 at 03:32
  • I think this is a really interesting question and I have not read any answer that I believe address it. There is only the standard, "it depend", and "do what is right". – elgrego Sep 03 '15 at 12:36

6 Answers6

20

The question I find a bit odd, because static methods and methods that perform no mutations are two orthogonal classifications of methods. You can have mutating static methods and nonmutating instance methods.

For me, it has become more and more natural to combine functional and oo programming; I like instance methods that perform no mutations. Functional programming is easier to understand because it discourages complex mutations; OO programming is easier to understand because the code and the data it operates on are close together. Why choose? Embrace the power of "and"; do both!

Eric Lippert
  • 647,829
  • 179
  • 1,238
  • 2,067
12

You can write working programs this way, but it's not idiomatic. If you want to work on a team, I'd try to curb it. If no one else is reading your code, go nuts.

recursive
  • 83,943
  • 34
  • 151
  • 241
  • 9
    Agreed. I think it's a mistake to write C# programs that look like F# programs, and vice versa. You should play each language and framework to its strengths, rather than try to fit them into a mold inherited from some other language or framework. If you're really sold on the F#/Scala model of programming, program in F# or Scala :-). – Ken Smith Feb 07 '11 at 23:18
6

For some reason I think of this quote when I read your question:

You can write Fortran in any language.

If the intent of C# were to be purely functional, static would be unnecessary because everything would be static by default. If you are strict about following OOP practices and the SOLID principles, your code effectively becomes functional (I know there's a quote out there about this somewhere) so you end up getting the best of both worlds.

The reason I would curb it in a multi-user project would be that it's not typical C# (it's really C# with handcuffs). You just need one person to break the rule and declare a static mutable property and everything goes to hell.

Austin Salonen
  • 49,173
  • 15
  • 109
  • 139
0

Not completely. I do like my extension methods, and Linq, but an OO-language should be used in an OO fashion. Besides, it's all imperative at the CPU, and for several layers on top of that.

KeithS
  • 70,210
  • 21
  • 112
  • 164
0

Great question.

I think the answer depends on the context of what your code does, and how much of it is static.

My code has been seeing less static cases since I program to interfaces a lot now and mark some methods 'protected virtual' rather than 'static' for cases such as unit testing's extract and override pattern. Thats not to say you couldnt just call static methods from those, though.

CRice
  • 12,279
  • 7
  • 57
  • 84
-2

There is many reasons should curb this instinct when you write OOP.

Object states and behaviours;

Static class and method need parameters, and you should be sure which paramters will pass to static methods. But class manages itself if method related with is state.

I think that only this reason enough to curb static modifiers.

And for clear reason, we should listen Mrs. Liskov. here

Nuri YILMAZ
  • 4,291
  • 5
  • 37
  • 43
  • What does the LSP have to do with static helper methods? – Ben Voigt Feb 07 '11 at 23:11
  • I will be surprised if I see any method modified by static in helpers with out "this" parameters. Static helpers methods are not really "static", it is only modified by "static". Someone must write some static method, and the best place in class body (there is noı choice in C#) method must be define in a class. – Nuri YILMAZ Feb 07 '11 at 23:19
  • 2
    @Ben - A static method cannot be substituted, one for another, without dependents knowing the difference. That violates several interconnected principles of SOLID, including LSP. If your program is heavily static, it is tightly coupled, requiring you to change code in more places than you would if it were organized any other way, even as a singleton. – KeithS Feb 07 '11 at 23:30
  • 1
    @Nuni: Prepare to be surprised. @KeithS: It's not bad for members on a class to be tightly coupled to other members of the same class. – Ben Voigt Feb 08 '11 at 00:27
  • @Ben Voigt: suppose SList : List and add few lines code for methods to SList. one day you need another FList : SList is useful. No? Ok. Prepare another Flist : List but i would like to use some methods from SList I do not want dublicate some methods. Should I use multiple inhertance? No! C# give change to add some method with static extensions. This is one of "real" reason to use static method. Of course when C# support multiple inheritance it wil be good surprise for me. And I am wondering what will we do many static extensions many assembiles and namespaces.Khaos? – Nuri YILMAZ Feb 08 '11 at 12:18
  • @Nuri: I don't think that the proposal is to use static methods instead of virtual methods, but rather to put most of the complexity in static methods called from instance methods. – Ben Voigt Feb 08 '11 at 13:31