Rewrite of the Question: Is there a technical reason why we are not using static methods instead of instance methods.
Technical reasons are for example: Performance or added type-safety.
I reason that with static methods and only pure data classes you will get better type safety and more maintainable code.
Why do we add methods to classes?
When I look at what the compiler does we can infer that an instance method on a class gets transformed into:
public static class Foo {
public static int Something(object this) { ... }
}
This shows us that even "under the hood" we just pass the data as a parameter to our methods, or more pointedly, functions.
What is the reasoning behind having instance methods?
My research has found three key reasons for adding instance methods:
- Convention, we've been taught to do it that way
- Ignorance, we do not know of another way
- Convenience, easier to find functionality, basically a way to group functionality.
I find all three reasons shaky at best. I think we can all agree that the first two reasons are not really valid reasons, this leaves us with the third reason, Convenience, but when you look at the calling code of an instance method you see something strange happen:
var o = new MyClass(..some parameters...);
o.Something(...some parameters...);
We have split our function signature over two lines. We have basically lost our chance of really type-checking changes made to our system. And comparing this to something like currying is not a valid comparison. Would using classes to express data and using functions (static classes with static methods) not be a better and even more convenient way to group data?
We could rewrite the previous calling code to:
StaticLib.Something(...some parameters...);
And just be done with it. Using the code would be easier to test and to implement and grouping the code is easy as well. Just use basic segmentation criteria on your collection of functions. You can even automate this grouping when you take types and signatures into account...
EDIT: As stated by @Daniel T. I seem to be coming down hard on convention. This is not what I want to convey. Convention is great when working in a big project or working with colleagues. Convention is also a really great way to bottle change, please read this next edit not as an attack on convention in projects but as an attack on convention as an argument for reasoning.
EDIT: I am not talking about OOP vs FP, we should all agree that polyglot solutions are best. I am not interested in answers like:
- Most programmers expect their code to look like....
- It is convention
- I've been taught to do it like that...
Those are answers based on convention and dogma and will never result in better ways of thinking or coding.
I am interested in proofs and solid reasoning. The accepted answer in the so called duplicate reduces the question to two things:
- It does not feel OO enough
- I don't like it
This is not a proof and is not an answer to the question. Furthermore I do not ask the same question so it's doubtful it's a duplicate.
EDIT: This is not a duplicate. I'm not interested in inheritance or other OOP aspects. Just about the quality and readability of the code.
(do-something x y z)
and the effective method being called would depend onx
,y
z
. But if you work in Java or C++, data and functions are encapsulated in a single entity which is the class, and here you have single-dispatch on the implicitthis
, which is read as the subject of an operation, separate from the arguments. This is neither worse nor better, it just is (I know which I prefer, though ;-).