How operator overloading is useful in class based programming?

Answer 1

The concept of Operator Overloading is similar to Method Overloading, in that the meaning of a given operator symbol changes according to the context it is being used in. That is, the semantics of the operator symbol are flexible, rather than fixed.

The idea behind Operator Overloading is to take a common symbol, and adjust it's meaning to something logical for contexts other than what it was originally restricted to.

The arithmetic operators ( + - * / ) are good examples. Using Operator Overloading, I could define that 'SomeArray + SomeValue' means that I should add SomeValue to the end of the array SomeArray.

In general, Operator Overloading is what is called 'syntactic sugar' - it makes things more readable. For instance, the equivalent way to do the above example via method calls would be: SomeArray.addToEnd(SomeValue)

The major problem with Operator Overloading is that it depends on people having the exact same interpretation of what an operator would mean in the new context, which is difficult to assure. Going back to the above example, there is some ambiguity as to where 'SomeArray + SomeValue' would mean to add in SomeValue - should SomeValue be added to the start of the array, or the end of the array? The answer is not obvious, and one would have to go look through the overload definition. While this confusion is also possible with methods, properly named methods (i.e. using addToEnd() rather than just add() ) helps avoid this entirely.

For this reason, Java does not support user-defined Operator Overloading. Java does support certain operator overloading in narrow contexts, but only those defined by the language itself. That is, the '+' sign is overloaded to allow for string concatenation. However, the designer of Java (James Gosling) decided that his preference was to avoid Operator Overloading completely due to his perception of a "clean" language.

Answer 2

Operator overloading allows consumers to use objects in intuitive ways. Every object should ideally have a complete set of the relational operators (<, <=, >, >=, == and !=) to perform intuitive comparisons. Every object should also have at least one assignment operator overload (to assign the members of one object to another). If the object is intrinsically a container, then you should provide a subscript operator ([]) to be able to return individual objects from the container. If the object is intrinsically numeric, then it should ideally support all of the arithmetic operators (+, ++, +=, -, --, -=, *, *=, / and /=), and possibly all the bitwise logic operators (|, |=, &, &=, ^, ^= and !). Cast operators should also be provided in order to provide transparent casting to other objects. That is, if your class can be constructed or assigned from another class of object, then it should be capable of being transparently cast to that type of object as well. In addition, every operator overload you provide must also provide an equivalent verb function. That is, if you provide the assignment operator (or use the compiler-generated assignment operator), then you should also provide a matching assign() function. The operator implementation should simply call the function in order to avoid unnecessary code duplication.

Operator overloading is less useful when the usage is ambiguous, non-intuitive or otherwise unpredictable. If the objects were people then you wouldn't expect to mathematically sum them or divide them. If there's ever any doubt, use a verb function instead. Only use operators when they are unambiguously intuitive.