Why do we add instance methods to classes? [closed]

Question

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.

Answer 1

One big reason is polymorphism (not inheritance, which is just one form of polymorphism).

Consider the following example:

interface Payable {
  ...
  double calculatePay();
  ...
}

public class HourlyEmployee implements Payable {
  ...
  public double calculatePay() {
    return hourlyRate * timeCards.totalHoursWorked();
  }
  ...
}

public class SalariedEmployee implements Payable {
  ...
  public double calculatePay() {
    return salary;
  }
  ...
}

public class PayRun {
  ...
  private PaySlip buildPaySlip(Payable payable) {
    PaySlip paySlip = new PaySlip();
    ...
    paySlip.setGrossPay(payable.calculatePay());
    ...
    return paySlip;
  }
  ...
}

If instance methods were just functions receiving the object as a hidden parameter, the code above wouldn't work. The caller of the method calculatePay would need to know which kinds of Payable objects exist in order to call the right function. With OO, that knowledge is not necessary, thus the PayRun object is capable of building PaySlips for any kind of Payable object. We can add CommissionedEmployee or any other kind without changing the core of the payroll process.

Of course, polymorphism is not even close to being exclusive to OO. However, it is a concept baked into the core of the paradigm (and related languages), making it a first-class feature instead of just something you can achieve (usually by doing things in unfriendly and unidiomatic ways, like virtual tables in C). However, I criticise statically typed languages like Java and C++ as being too constrictive about polymorphism. Languages that cheaply support duck-typing are better subjects of study to understand the reasoning behind OO.

Answer 2

Don't underestimate the power of convention. If everybody does things the same way, it makes big programmes more maintainable.

---

Your example StaticLib.Something(...some parameters...); only looks simpler because you've glossed over the details. You haven't actually stated where the MyStruct data is initialised, nor passed it into the Something function.

I'm assuming that you're doing structured programming, rather than just procedural code with thousands of variables all over the place. If we're going to do structured programming, we need to store the program data in a collection of structures/classes. All the popular coding guidelines insist that data must be initialised before it is used. So let us assume that we have a structure MyClass to hold data about something. We need to create the structure and initialise to to a known state.

MyClass o = StaticLib.CreateMyClass(... initial state ...);

or perhaps

MyClass o; StaticLib.InitMyClass(o, ... initial state...);

Now we want to do something with o.

StaticLib.Something(o, ...some parameters...);

Put it together, and you get

MyClass o = StaticLib.CreateMyClass(... initial state ...);
StaticLib.Something(o, ...some parameters...);

At which point, you might as well do it the "object oriented way", and just write

MyClass o = new MyClass(... initial state ...);
o.Something(... some parameters...);

---

Object Oriented programming also naturally gives a better program structure. The definition of the data structure is always closely associated with the functions that operate on it. That's easier to maintain than a definition of a data structure in one place, and a library of functions that operate on it somewhere else.

---

And finally, it just looks nicer to write

lion.Roar(LOUDLY);

than

Animals.Roar(lion, LOUDLY);

Answer 3

I think it might be Java related, where everything has to be in a class (even when, as you point out, its not ever in an instance of a class).

C++ allows normal functions, but also maintains the static keyword that used to constrain a variable or function's scope to the containing file. C++ kept this meaning but modified the scope to the containing class, even this its more a namespace thing as you still have to allocate the storage space for it externally.

This is a good reason why its done - to limit definition scope, so someone reading your code knows that a static variable or function is only referred to inside (or with relation to) a particular class, even though its not tied to individual instances.

Answer 4

Once you remove dynamic dispatch from the mix, the answer is that there is no reason, other than convention, that we do it that way.

In English, we read/write from left to right. Why? No reason other than convention. I get the impression that you are being much too quick in discarding convention. Conventional code is easier to write, easer to read and easier to maintain...

a = b.c(d, e).f(g).h()

vs

a = h(f(c(b, d, e), g))

The former reads more naturally from left to right than the latter. Since we English speakers are trained to read from left to right from a very young age, such construction makes the former easier to read and write.

In the former, there are no nested parentheses. Because of that, we are less likely to put in too many, or too few close parens, and we can more easily see that the parens are balanced. This makes the former easier to write and read.

When code is easier to read, it's easier to maintain and understand. When it is easier to write, it is more likely to be written correctly the first time.

Do your friends, including future you, a favor and make your code easier to read and write.