Should two overloaded methods be allowed to behave in a completely different way?

Question

as from title. Is it considered acceptable that two methods, say foo() and foo(int), perform two unrelated operations ? and why ?

Edit : thanks. I see that I am not the only one thinking that is heresy. :)

Answer 1

Not acceptable.

Because it will break the user expectation, resulting in communication-error bug.

IMO it would be clearer to use different method name for different operations.

Oh wait, there is one situation whereby you might want to do this. If you think that your code is so precious that it needs obfuscation and that the current obfuscation tool isn't good enough and you absolutely positively must do it manually, then be my guest.

Answer 2

No. Because the method name should describe the 'method' - ie. the method of operation of the code contained within.

Overloading is for convenience.

Answer 3

Absolutely not! Why would you confuse potential clients of your code and maintainers by overloading a method and then have it's implementations perform unrelated tasks? It's not as if names are at a premium.

Answer 4

The problem may be in naming scheme.

If your method names are consistent with their function, then you cannot have two methods with the same name doing different things.

Answer 5

Why it is not acceptable?

Because you design classes and methods to decrease the complexity of a program, both in term of code and semantic.

Having two methods with the same name but different signatures and behavior would break the semantic encapsulation and increase complexity (forcing the user to think carefully to the actual consequence of calling one or the other function)

Hence the "non-acceptable" part.

---

From Code Complete:

Syntactically, it's relatively easy to avoid poking your nose into the internal workings of another class just by declaring the class's internalroutines and data *privateù.
Achieving the semantic encapsulation is another matter entirely.
[...]

(your example would)

make the client code dependent not on the class's public interface, but on its private implementation

(here foo() has a significant different implementation then foo(int))

Anytime you find yourself looking at a class's implementation to figure how to use the class, you're not programming to the interface; you're programming through the interface to the implementation.
If you're programming through the interface, encapsulation is broken; and once encapsulation starts to break down, abstraction won't be far behind.

Answer 6

The only case where I've seen anything like that, that didn't look extremely bad, was when a getter/setter pair had the same name. I've seen some libraries that take that style. I'm not sure I particularly like it, but it doesn't seem too unreasonable.
Of course a getter and setter are really two extremely related functions, they are just opposite sides of the same coin.

Answer 7

No!

This and other programming language features are to make the code easier to read/understand/maintain/evolve. If you have two methods with the same name doing completely different things, you get the opposite: confusion.

Answer 8

Well, as soon as the method name still describe the action, it should still valid.

Answer 9

Short answer: no.

Slightly longer answer: turn the question around - why take two methods which perform unrelated operations and give them the same name?

Answer 10

Yes. In certain cases, it follows the principle of least surprise. Consider the C++ minus operator:

operator-(void);
operator-(const Other & o);

When used by itself on a number class, it reverse the sign. When used with an argument it performs subtraction.

Answer 11

No!

Overloading methods makes things complicated enough as it is (Ideally, I wouldn't ever overload methods at all, but that is impossible in practice).

There's no need to complicate things even further by making the result of those methods unpredictable for people that use the code later on.

Answer 12

For pure convenience, yes - example of it is in the jQuery library where if you invoke an event handler method such as bind or click internally it maps them to two distinct methods, in this case bind or trigger depending on whether a function was passed ( which evaluates to true and calls bind or if no argument was passed then undefined is false and so it triggers the event handlers ).

jQuery.each( ("blur,focus,load,resize,scroll,unload,click,dblclick," +
    "mousedown,mouseup,mousemove,mouseover,mouseout,mouseenter,mouseleave," +
    "change,select,submit,keydown,keypress,keyup,error").split(","), function(i, name){

    // Handle event binding
    jQuery.fn[name] = function(fn){
     return fn ? this.bind(name, fn) : this.trigger(name);
    };
});

waits for downvotes

Answer 13

No ...

Overloads should be considered variations on a theme. Their overall functionality should be the same as each other, and differ only in the inputs they accept.

Often overloads are used to provide default parameter values (in C#). e.g.

// This signature allows for doing special processing
public void ProcessItem( int index, bool doSpecialProcessing );

// Most of the time special processing is not required, so call
// this method
public void ProcessItem( int index )
{
     ProcessItem( index, false );
}

Answer 14

Some people use the name "method" when they mean "operation" (which is part of a class' public interface).

If you mean "method" in the internal "how something gets implemented" sense, then the answer is NO almost by definition because "how" implies "what".

If you mean "operation", then YES. Implement the operation using whatever methods make the most sense in relation to the given parameter list. For example, if instead of "foo", you have "save(theOrder)" and "save(thePassenger)", I suspect they would behave very differently.