CODEWITHSUNDEEP
c#operator-overloading
Mocco
Mocco

Reputation: 1223

Operators overloading

Learning C# I have read about operators overloading. Unfortunately the book I am using is not much practical rather then theoretical so I would like to make sure I get it well. Also basically overloading operators allow me to make operations with my types. Like I have class Enemy and I could do Enemy+Enemy=SuperEnemy (instance of Enemy with e.g. sum of attributes) Is that right?

Upvotes: 2

Views: 2072

Answers (6)

KeithS
KeithS

Reputation: 71565

From a conceptual standpoint, yes; overloaded operators allow you to implement some logical behavior for the operator, so your objects can be manipulated in a more natural way. Take, for instance, a Money class:

public class Money
{
   public decimal Amount {get;set;}
   public string Unit {get;set;}
}

Money is generally treated as a number and so it would be nice to be able to add and subtract Money to get sums and differences; however, the monetary unit (USD, CND, EUR, JYN) describing the money makes a big difference in how they're added; Adding 100JPY + 100USD != 200USD OR 200JPY. So, you'd likely overload the operator to ensure that the monetary units are similar, or convert one to the other (100JPY ~= 1USD):

//in the above Money class
public static operator + (Money a, Money b)
{
    if(a.Unit != b.Unit) throw new InvalidOperationException("Cannot perform arithmetic on Money of two different types.")
    //or, create some helper that will convert the second term
    //CurrencyConverter.Convert(b.Amount, b.Unit, a.Unit);
    return new Money{Amount = a.Amount + b.Amount, Unit = a.Unit};
}

Upvotes: 2

slippyr4
slippyr4

Reputation: 862

What he said.

Enforce the rule that you only every operator overload when it makes perfect sense in the code for the various types involved. That being, that it makes logical sense to add Type1 and Type2 together, and it's logical that that addition would result in a Type3 that makes sense.

Your example above fails that rule: it doesn't follow that 2 enemies make a SuperEnemy. Personally, if I needed that logic I would have a static method to create a SuperEnemy like:-

class SuperEnemy
{
  public static SuperEnemy FromEnemies(Enemy a, Enemy b)
  {
  }
}

A better example of something that you might appropriately use operator overloading for is a color. You can add two colors together and get a third color, a blend of the two. So:-

public static Color operator +(Color a, Color b)

would be a sensible overload to implement.

In a real-world example: I have a class which represents a 2-dimensional coordiate, and another which represents a 2 dimensional vector (i.e. a translation).

Coordinate + Coordinate = makes no sense - don't overload

Coordinate + Vector = A coordinate

Vector + Vector = A new vector representing the combination of the two vectors

I hope that helps

Upvotes: 0

gjvdkamp
gjvdkamp

Reputation: 10516

A good example would be for instance creating a class for complex numbers, they have operator +, -, * etc, but behave difefrently than normal numbers.

Here's an article on that: http://msdn.microsoft.com/en-us/library/aa288467(v=vs.71).aspx

Another good place to use them would be in creating immutable classes.

class SomeCoordinate{
  public int X {get;private set;}
  public int X {get;private set;}

  public SomeCoordinate(int X, int Y){
    this.X = X;
    this.Y = Y;
  }

  public static SomeCoordinate operator + (SomeCoordinate left, SomeCoordinate right) {
    // instead of changing the class, create a new one
    return new SomeCoordinate(left.X + right.X, left.Y + right.Y);
  }
}

} GJ

Upvotes: 0

Carlo V. Dango
Carlo V. Dango

Reputation: 13832

While operator overloading is possible in C# it is something you should steer clear from! It really only makes sense in very narrow domains such as if you were implementing your own number class (say a complex number class). In such cases you may find it useful. But you should ask yourself, how often do you really create such classes... in reality never! A more likely example is a Money class or a Date class in business applications. But even here I would argue, that going down the path of operator overloading is wrong when if the logic for adding two instances is more than 1-2 lines of code. Especially date-classes are tricky and have all sorts of business requirements associated with them - and such requirements should be made clear in the code by the use of methods, not by hiding them under operator overloading.

Note though, that some operators are worse overloaded than others. Many feel the urgency to overload == (to mean Equals()). This is absolutely horrible, as you then have difficulties reading the code. Especially when said people forget to overload eg. !=

Others are of the religion that it's ok to overload + but for bigger objects, it may not be entirely clear 1) what that means, and 2) it seriously obfuscates the code. That being said, I may be able to live with someone overloading + while I cannot accept anyone overloading ==

Upvotes: 0

Jens
Jens

Reputation: 3299

As long as you have the code to handle the sum you can do that yeah. But getting your SuperEnemy object with a sum of the attributes requires code to make those sums.

It ain't going to work by just writing object + object = ...

Take a peek at this: Operator Overloading

Upvotes: 0

Jon Skeet
Jon Skeet

Reputation: 1499800

Yes, you can do that. I would suggest you only do it very, very rarely though. It's easy to end up with hard-to-understand code that way

An example of where it's done usefully would be

DateTime operator +(DateTime dateTime, TimeSpan timeSpan)

so you can add a TimeSpan to a DateTime to get another DateTime.

Upvotes: 1

Related Questions