-1

When writing code in a programming language that has the option of creating standalone functions vs. methods of a class or struct, what is the most relevant objectively-quantifiable reason to choose to implement any specific functionality as a method of the class or type instead of using an independent function that just accepts the object as a parameter?

(This question completely changed from original — which sfiss's answer was in response to — as the original was closed for for being unfocused.)

Improve this question
6
  • 1
    I feel like this will be quite language specific.
    – bdsl
    Mar 20 at 20:12
  • 1
    i voted to close because "opinion-based", not "needs more focus
    – user253751
    Mar 20 at 20:49
  • Would it make logical sense for the function to require access to an object of a class? If so, method. Otherwise, standalone function.
    – user16217248
    Mar 22 at 5:34
  • 2
    I don't see why one of the fundamental features of OO languages, must be "opinion-based" or "unfocussed". There must be design rationale, including from the language designers themselves.
    – Steve
    Mar 22 at 7:42
  • @Steve sometimes there aren't "objectively-quantifiable reason[s]", just opinion-based ones
    – Caleth
    Mar 22 at 15:46

1 Answer 1

Reset to default
4

One aspect of this is which paradigm you follow.

If its OOP, one rule of thumb could be: put it on the object if you need its internal state (dont violate law of Demeter, encapsulate state and expose behavior, tell dont ask), and else its a standalone function.

If its a functional approach, the struct is most likely only (immutable) Data, so standalone (pure) function works well.

I guess the most critical rule of thumb is: do it in a consistent way, whichever direction you choose.

Improve this answer
11
  • In OOP, I'd say the key determinant is whether you want polymorphism or not. The a in a.m(b, c) is not equal to the a in f(a, b, c). It (solely) determines the implementation of m that gets invoked.
    – Alexander
    Mar 22 at 3:01
  • @Alexander You can have a scheme where b and/or c get a say in it too.
    – Caleth
    Mar 22 at 15:44
  • @Caleth Yep, you can hand-roll single (or even multiple) dispatch with a plain function, but the point I was trying to convey is that most OOP languages give privileged behaviour to the a in a.m(b, c), in that it gets single-dispatch automatically without you needing to hand roll anything.
    – Alexander
    Mar 22 at 16:28
  • @Alexander I meant you can do multiple dynamic dispatch with OO, and dispatch on the static types of a, b, c is still polymorphic
    – Caleth
    Mar 22 at 16:31
  • @Caleth I'm not sure what you mean. Are you referring to how if you have function overloads all called f, that accept different types, that calling them with a, b, c will pick the correct one according to their static types? That's "ad hoc polymorphism". That's not "multiple dynamic dispatch," because it happens at compile-time, based only on static types, without any runtime consideration of the concrete types being used. I was talking about runtime polymoprhism ("subtype polymorphism").
    – Alexander
    Mar 22 at 16:38

Not the answer you're looking for? Browse other questions tagged or ask your own question.