Object-oriented – n alternative to the term “calling object”

object-orientedterminology

Let's suppose you've got a class defined (in pseudocode):

class Puppy {
    // ...
    string sound = "Rawr!";

    void bark() {
        print(sound);
    }
}

And say, given a Puppy instance, you call it's bark() method:

int main() {
    Puppy p;
    p.bark();
}

Notice how bark() uses the member variable sound. In many contexts, I've seen folks describe sound as the member variable of the "calling object."

My question is, what's a better term to use than "calling object"?

To me, the object is not doing any calling. We know that member functions are in a way just functions with an implicit this or self parameter.

I've come up with "receiving object" or "message recipient" which makes sense if you're down with the "messaging" paradigm.

Do any of you happy hackers have a term that you like to use?

I feel it should mean "the object upon which a method is called" and TOUWAMIC just doesn't cut it.

As for who the "caller" is, I would say that main instantiates a Puppy object and calls its bark() method.

Best Answer

Using the word object in the reference is redundant.

Perhaps caller and callee is simplistic enough. Referring to the actual object as an instance of type is also another approach as noted by Wyatt; instance of Puppy or if being succinct is the goal...instance.

Related Solutions

DRY Principle – Understanding Violations and Anti-Patterns

it is just called duplicate code - I don't know of any more fancy names for this. The long term consequences are as you described, and worse.
Of course, eliminating the duplication is the ideal option if only possible. It may take a lot of time (in a recent case in our legacy project, I had several methods duplicated across more than 20 subclasses in a class hierarchy, many of which had evolutionarily grown their own slight differences / extensions over the years. It took me about 1,5 years through successive unit test writing and refactoring to get rid of all duplications. Perseverance was worth it though).

In such a case, you may still need one or more of the other options as temporary fixes, even if you decide to start moving towards eliminating the duplication. However, which of those is better depends on a lot of factors, and without more context we are just guessing.

Lots of small improvements can make a big difference in the long run. You don't necessarily need the customer's explicit approval for these either - a little refactoring every time when you touch said class to fix a bug or implement a feature can go a long way over time. Just include some extra time for refactoring in your task estimates. It is just like standard maintenance to keep the software healthy in the long run.

C++ Interfaces – Understanding the Term ‘Interface’ in C++

In C++, the term "interface" has not just one widely accepted definition - so whenever you are going to use it, you should say what you mean exactly - a virtual base class with or without default implementations, a header file, the public members of an arbitrary class and so on.

Concerning your example: in Java (and similar in C#), your code probably would imply a separation of concerns:

interface IFoo {/*  ... */} // here is your interface

class FooBase implements IFoo 
{
     // make default implementations for interface methods
}

class Foo extends FooBase
{
}

In C++, you can do this but you are not forced to. And if you like to call a class an interface if it has no member variables, but contains default implementations for some methods, just do so, but make sure everyone you are talking to knows what you mean.

Related Topic