1

Take the (unprecedented and groundbreaking) example of the calculator:

public class Calculator
{
    public double Add(double augend, double addend) 
    {
        return augend + addend;
    }
}

When I write calculator.Add(val1, val2) which of the following am I doing?

  • Telling the calculator to add the inputs
  • Adding the inputs with the calculator

(One could also ask: "Is it a method of the object or is it a method on the object?")

Other examples: do we tell the repository to add the entity or do we add the entity to the repository? Do we tell the message service to deliver a message or do we send a message through the message service? Do we tell the can of paint to mix itself or do we mix the can of paint?

Improve this question
6
  • Unclear what help you need. Please clarify your specific problem or provide additional details to highlight exactly what you need. As it's currently written, it’s hard to tell what problem you are trying to solve or what aspect of your approach needs to be corrected or explained. See the How to Ask page for help clarifying this question. – gnat May 13 '14 at 16:45
  • 1
    It's not necessary either of your two choices. Maybe it is a message to the object. – hyde May 13 '14 at 16:45
  • @gnat "Programmers Stack Exchange is a question and answer site for professionals and students in software development and related fields who are interested in getting expert answers on conceptual questions about software development." – user44798 May 13 '14 at 16:49
  • 1
    This question appears to be off-topic because it is about vocabulary. – Doval May 13 '14 at 17:09
  • 1
    Most programming languages are actually meta-languages. You use them to develop the business language that you will use to solve your problem. That means it is up to you to put in the meaning most appropriate for your problem domain. If it makes more sense to mix the paint then mix the paint, but if your problem requires the paint to mix itself then define the paint to mix itself. You get to decide what is most appropriate for your current situation, and then do that. – YoungJohn May 13 '14 at 21:15
4

is it a method of the object or is it a method on the object?

It is a method of the class.

You create instances of classes to encapsulate state, not code. All of the code in that method is the same code across all of the objects; only the state (private variables) varies between objects.

Calling methods is a form of message passing. You send a message to an object by calling a method. The method can send back a message of its own by returning some value. The method may also cause side effects by altering the state of the object, writing to a log, etc.

Do we tell the can of paint to mix or do we mix the can of paint?

If you call

canOfPaint.Mix();

You are telling the can of paint to mix.

If you call

Mix(canOfPaint)

You are mixing the can of paint.

Improve this answer
10
  • I have been thinking like that for as long as I have been developing but I want to know why. Why think of methods as actions that objects can do rather than actions that we can do with objects? Or is there room for both, as @Prog touches on? – user44798 May 13 '14 at 18:13
  • Because generally you want your behavior and your state to be encapsulated in the same place, generally within the class definition. That's one of the primary motivators of OOP. – Robert Harvey May 13 '14 at 18:21
  • Right, and I wouldn't want to have everything be a bag of public getter/setters with static helper libraries. Encapsulation is important and I'm not advocating against it. I'm just trying to figure out, given an instance of a class with some logic encapsulated in its methods, how am I to best describe and conceptualize the usage of those methods? – user44798 May 13 '14 at 18:35
  • I want to personally thank you for your discussion as well. I know the matter might be trivial to a lot of people but I never would have expected the negativity and dismissal that I received from the beginning. – user44798 May 13 '14 at 18:37
  • It mystifies some of us that you are wrestling with something that seems so self-evident. Programming languages are called "languages" for a reason; they conceptualize things just like "real" languages do. So when you say Mix(canOfPaint), you're mixing a can of paint, just like the code says. When you say canOfPaint.Mix(), you're telling the can of paint to mix itself. Just like the code says. There are valid use cases for both approaches. – Robert Harvey May 13 '14 at 18:41
0

In my opinion it's a matter of the context in the system, and sometimes depends on the conceptual role of the component in the system.

For example in a game, a character might have a method attack(). Is it meant to allow other characters to attack this character? Or is it a method used to tell the character to attack? Totally depends on your system.

Improve this answer
2
  • Hopefully the code is written clearly enough that the context is apparent. – Robert Harvey May 13 '14 at 17:01
  • You could even take it to the point of 'making an attack with the knight' by having the 'attack' method produce an attack object that is evaluated elsewhere. Maybe it's all just preference -- but then some would say that "tell, don't ask" is not a preference but a best practice. I'm just trying to make it all click. Thank you for not brushing me aside. – user44798 May 13 '14 at 18:33
0

Generally speaking, it doesn't matter.

If you're telling a Calculator object to add, your code looks like this:

class Calculator {
  public Double add(Double a, Double b) {
    return a + b;
  }
}

If you're adding two number with a Calculator, it looks like this:

class Calculator {
  public Double add(Double a, Double b) {
    return a + b;
  }
}

The implementation is the same. And I suspect your code will be the same in most cases regardless of which preposition you use to describe it. In most cases, your object is both the subject and direct object of the verb. In cases where it won't be the same, you should try to clarify the method name or include adequate documentation to indicate what role the object plays in the action.

Improve this answer
4
  • Well... sort of. In a curly-brace language with classes, your second example would be a static method in a static class. While this seems like an inconsequential distinction, the first example does require you to instantiate an object, while the second one (if it is made static) does not. The distinction between to and with matters less than whether or not you plan to hold state (such as a total). – Robert Harvey May 13 '14 at 20:47
  • I think this is the best answer I can hope for. I have to break myself of interpreting object.Method() as always having 'object' as the subject. Assert.AreEqual(true, (code.IsLike(english) && !code.Equals(english))); – user44798 May 13 '14 at 21:12
  • @tuespetre: True enough. A method can act on the object you call it on, but it can also act on some other object instead, if you pass it into the method's parameter(s). – Robert Harvey May 13 '14 at 21:14
  • Hmmm, I think your point is sinking in, @RobertHarvey. Since static methods can access the internals of instances of the same class, perhaps I could reserve instance methods for things that the instance does and use static methods for things you do with. – user44798 May 13 '14 at 21:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy