Wiki Home

The No Overloading Principle


Namespace: WIN_COM_API
Here's a take by BertrandMeyer, essentially arguing against method overloading, in the Oct / Nov 2001 issue of Jo OP.

"Different things should have different names"

http://www.inf.ethz.ch/personal/meyer/publications/joop/overloading.pdf

I wrote something here. Was it removed intentionally? -- Mike Helland
This has seemed "obvious" to me since I learned Java 5 years ago. Just because you "can" do something doesn't mean you should. The examples re overloading seem to deliver little useful benefit to long-term development.
I'm curious to know what people think of overloading in environments like VFP where the type and number of parameters can be very flexible. I do it all the time. Certainly the ability to pass objects of any type is a huge bonus. In my view.
Upside
  • Client code can be loose
    Downside
  • Client code can be loose < s >
  • More preamble code in functions and methods to sort out the parameters.
    -- Steven Black

    I can see that you are mimicking Overloading with check code. But I'll bet your code does the same thing when called, simply allowing different input. If Overloading were confined to handling different signatures for the same method, I'd agree.
    However IME Overloading is often used inappropriately because it is there. E.g. some common examples like "Shape()" that has multiple constructors and does different things depending on number of parameters, is far harder to maintain or "read" in calling code than using different methods Ball() Square() Triangle() etc.
    And unless you can stop programmers mixing inheritance, overriding and overloading you risk huge complexity.

    FWIW, Method Overloading is one of the main techniques used by Obfuscation tools that seek to render dotNET code unreadable or confusing. < g >

    The "decision" I reached was that debugging/maintenance is hard enough, if you have a need to handle more than one input in bespoke code, why not create multiple methods of appropriate name. Functionally this is no different from overloading but it is a great deal easier to maintain in 6 months. -- John Ryan
    I think anytime you offer a developer the choice of which parameters are required/necessary for a function, you have a good case for an overloaded function call. You’re essentially letting the compiler do the parameter checking for you, so you don’t end up with a ton of: IF VARTYPE(tcMyVar) = “C” code. Why code things if the compiler will do it for you “for free”? As with most OO code, it can be taken to extreme and used inappropriately. That doesn’t mean it’s not useful; remember how many people say inheritance isn’t necessary? It might not be, but I’m certainly happy to have it.

    I think overloaded methods are much more important in a strictly typed language than they are for a language like VFP. So, for VFP, I would agree w/the Upside & Downside list. For a strictly-typed language, the client side code can’t be “loose”. It MUST conform to one of the method signatures, otherwise it will throw an error. -- Paul Mrozowski
    Does this old topic Operand Principle have relevance to the discussion?
    Category Principles And Guidelines
  • ( Topic last updated: 2002.08.12 02:50:39 PM )