CODEWITHSUNDEEP
c#oopinterfacec#-3.0
Dyppl
Dyppl

Reputation: 12381

Overloaded methods in interface

my question for today: are overloaded methods in interface bad? You know, the "omit parameters if you don't care, we'll figure out the default values" kind of overloaded methods. Like that:

void Add(object item); 
void Add(object item, bool shouldDoSomething); 
void Add(object item, bool shouldDoSomething, IUltraObscureDeviceContext context);

In this case I tend to think that only the latter belongs to an interface and others should be implemented in abstract class on top of it. But then again, I'm not sure.

Also, there are times when you just want different overloads doing slightly different work (stop me right there if overloaded methods should never be used for that). Or sometimes you can't just stuff nulls in place of some parameter, you want the exception thrown if something is null. Should I not use overloading in this case?

So basically I'm looking for some guidelines on overloaded methods in interfaces vs overloaded methods in abstract classes implementing these interfaces and so on. Thanks in advance

Upvotes: 22

Views: 25076

Answers (3)

Shiv Kumar
Shiv Kumar

Reputation: 9799

Overloaded methods in an interface maybe Ok if the design of the interface warrants it. I've personally never needed to do this.

I wouldn't define default parameters values in an interface. That is an implementation detail that implementing classes that choose to surface.

you comment about having different implementations for the overloads....

Don't do that. Think of implementation of these overloaded methods as calling the one method that has all of the parameters defined with some default values. That's how users of your code would expect things to be.

If you need different behavior then use polymorphism. That's what its there for.

Upvotes: 1

Jeffrey Hantin
Jeffrey Hantin

Reputation: 36494

If the defaults depend on the receiver of the method call, declare them as interface methods.

If the defaults are just defaults irrespective of the receiver, create the various reduced-argument-list overloads as extension methods and save implementors the headache of having to supply all the overloads themselves.

If you're dealing with some sort of nitty-gritty 80/20 rule exceptions, where implementation-independent defaults are almost but not quite always sufficient, you have a few options, none of which are that good:

  • Deal with it as if they're always different, declare them as interface methods, and reimplement them everywhere. Not very DRY.
  • Deal with it as if they're always different, declare them as interface methods, and inherit a base class that provides the 80% default implementation. Kind of clumsy, and not good if your sole base-class slot is already occupied.
  • Create another interface containing those specific methods. Declare extension methods with matching signature against the original interface. In the extension methods, as-cast the this argument to the new interface type, and if it matches, call it there, otherwise fill in stock defaults. Very funky, reliant on dynamic casting so not that great in an inner loop, but it decouples the defaults from both implementor and caller without sacrificing flexibility for implementors that can't take the "default defaults".

Upvotes: 11

Perpetualcoder
Perpetualcoder

Reputation: 13571

IMO if the interface/contract spells it out, there should be no problem. However the goal is to simplify things when exposing an interface and hide the details. And thats where optional params come in handy.Pefectly object oriented languages like Python do not even have overloading AFAIK

Upvotes: 0

Related Questions