Operator overloading lets you redefine how built-in operators (+, -, ==, <, etc.) behave when applied to instances of a custom class, so objects can be combined with intuitive, natural-looking syntax instead of always calling explicit methods.
Without operator overloading:
v1 = new Vector(1, 2)
v2 = new Vector(3, 4)
v3 = v1.add(v2) // works, but less natural to read
With operator overloading (Python-style example):
class Vector:
def __init__(self, x, y):
self.x = x
self.y = y
def __add__(self, other): # overloads the + operator
return Vector(self.x + other.x, self.y + other.y)
def __eq__(self, other): # overloads the == operator
return self.x == other.x and self.y == other.y
def __str__(self): # overloads how print() displays it
return f"({self.x}, {self.y})"
v1 = Vector(1, 2)
v2 = Vector(3, 4)
v3 = v1 + v2 # now reads naturally: (4, 6)
print(v1 == v2) # False
This is especially natural for mathematical or physical concepts — vectors, matrices, complex numbers, money/currency amounts, dates and durations (date2 - date1 returning a duration) — where the operator has an obvious, unambiguous real-world meaning.
Language support differs significantly: Python (__add__, __eq__, etc.), C++ (operator+), and C# support true operator overloading. Java and PHP deliberately do not — Java's designers considered it prone to abuse (creating confusing, non-obvious behavior), and instead require explicit named methods like .add() or .equals().
The main risk with operator overloading: it's easy to overuse in ways that surprise readers — overloading + to do something unrelated to addition (say, string concatenation on a Vector class) violates the principle of least astonishment and makes code harder, not easier, to understand. Reserve it for cases where the operator's meaning is genuinely intuitive and unambiguous for that type.