C # Operator overloading - to practical

Most websites, articles that I read, explain operator overloading by providing the following standard examples.

class Complex { int real; int imaginary; public Complex(int real, int imaginary) { this.real = real; this.imaginary = imaginary; } public static Complex operator +(Complex com1, Complex com2) { return new Complex(com1.real + com2.real, com1.imaginary + com2.imaginary); } public override string ToString() { return (String.Format("{0} + {1}i", real, imaginary)); } } } 

We, as beginners think, overload operators, would be very useful for scientific applications.

Will operator overload be very useful for e-commerce, ebanking or other applications? Since we saw the standard example above, it’s rather difficult to understand the real power of the operator overload. Please explain this by providing an example as needed.

+4
source share
5 answers

The applications you mentioned usually use addition and subtraction (and other necessary maths), standardized operations, so no overload is required.

For all other operations, I prefer to use methods.

A scientific example is useful for operator overloading because it redefines mathematical operations in terms of a data type that is not known to the system. If you want to create a custom object that can be semantically added or subtracted by another instance of a special object, operator overloading may be required.

But caution should be exercised. Overloading should make conceptual sense for other programmers. To provide a trivially absurd example, it is completely possible (but not entirely acceptable) to define addition as a subtraction.

+2
source

Just an example of operator overloading from the .NET Framework

 Console.WriteLine(DateTime.Now + TimeSpan.FromDays(1)); 

As you can see, this is not "scientific." Let it be so. If you work with data structures where it is generally known what to do with subtraction, addition, or logical operation, use operator overloading. If you come up with your own structures and rules, you better use methods. The rule is that using an overloaded operator should be really natural, not only for you, but also for other developers reading your code.

+1
source

Ok, here is an example. I have an application in which many domain objects include an attribute that indicates "Calendar Month" where a particular day of the month is relevant. (December 1998, March 2003, etc.)

So, I created a structure that represents these values ​​within myself as a primitive integer (the number of months since January 2000, I think). This structure includes many methods for creating instances of this CalendarMonth structure from different input types (DateTimes, strings that can be converted to date or time or year in a year, etc. The structure has methods CalendarMonth Parse(string inputValue) and bool TryParse(string inputValue out CalendarMonth calMonth) , as these bits of functionality are used throughout this application.

This structure also encapsulates methods that return dateTime values ​​for the first month, last day of the month, beginning of the month UTC, etc. etc.

It also has many operator overloads, so I can “add / subtract” a time span in a calendar month and get CalendarMonth or subtract two CalendarMonth structures to get TimeSpan ... kind of like datetime. It also has both implicit and explicit cast operator exploits to cast back and forth between datetimes and CalendarMonth structures ...

I would say, in general, this method is useful at any time when you have a Type in your Domain that could be called a value type (in the sense that it does not have an identifier), but it is determined simply by its attribute values, and which has “strong” quantitative properties of behavior in the problem area in which your application lives.

+1
source

@ Robert agreed. If you need to change the operator, just write a function or "method". Overloading the operator, in my humble opinion, is not only unnecessary, it makes your code almost unreadable

0
source

Please do not abuse operator overload if you can help him in any way. The problem is code readability - it's easy to understand what you see:

 CustomerCart cart = new CustomerCart(); IList<Purchases> purchases = this.GetPurchases(); 

and then in the code:

 bool success = cart + purchases; 

This would certainly force me to do a double trick. With the more "primitive" types you came up with, such as Complex , you can avoid this, but usually with high level types you want to avoid overloading, as it confuses the code.

0
source

All Articles