can anybody help me. can we use overloading only in same class or in dericed class also

Question

1.78/5 (3 votes)

See more:

C#

Posted 11-Mar-15 9:47am

Member 9425683

Add a Solution

3 solutions

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Sergey Alexandrovich Kryukov · Answer 1 · 2015-03-11T10:12:00

Solution 1

"Overloading" it almost irrelevant to inheritance and OOP in general.

[EDIT]
Please see our discussion with manchanx in comments to this answer. Strictly speaking, it is relevant in some more delicate cases, when the priorities in choice between possible different interpretations of the call statement come into play. See also the article referenced.
[END EDIT]

Many have been confused with this bad term: nothing is really "overloaded", because nothing is loaded. This is nothing but the absence of the requirement to have unique method names, as soon as a compiler has a way to infer which of the methods with the same name is meant at the line of the call, by "looking at actual arguments passed". It is just a matter of convenience, having a set of methods doing nearly the same but based on different set of parameter. Simply use this logic and feel free to define several methods with the same name, no matter where the other methods are, in the same class, in a base class or any derived classes.

Only do it the way it would be convenient for developers and self-describing. Don't worry too much about the compiler: if you break the rules, it will "tell" you and give you the chance to fix either the method profiles or the name. In practice, this is way too easy.

—SA

Posted 11-Mar-15 10:12am

Sergey Alexandrovich Kryukov

Updated 12-Mar-15 5:06am

v2

Comments

[no name] 11-Mar-15 16:37pm

Really good explanation! 5ed. But I think there's one gotcha a beginner can run into: Overloading on argument types of an inheritance chain.

Sergey Alexandrovich Kryukov 11-Mar-15 21:52pm

Do you mean covariance/contravariance? True, but this is a separate issue totally unrelated to "overloading" itself. Besides, I believe people rarely run into this kind of complication, really rarely.
Thank you.
—SA

[no name] 11-Mar-15 21:58pm

I think I have to sleep before replying ;-) But you're definitely right, it's a rare thing.

edit: Found it, see here (section "Inheritance"): http://csharpindepth.com/Articles/General/Overloading.aspx
(Though it's not exactly what I wrote in the first comment.)

Sergey Alexandrovich Kryukov 11-Mar-15 22:55pm

Okay, I see. This is a very interesting example which is good to know; and the "silent" incompatibility between versions is outrageously disturbing. I just checked it up, it really works as described. Will you post this link as additional solution (I'm not sure how much it is related to the original question though :-)?
—SA

[no name] 12-Mar-15 9:22am

You're talking about what he wrote under "Introducing a new conversion is a breaking change", right? I meant the part under "Inheritance" - which is more related to the original question I think.

Sergey Alexandrovich Kryukov 12-Mar-15 11:03am

Yes, I was talking about C# In Depth -> Overloading -> Introducing a new conversion is a breaking change, just because you means something that is usually related to covariance of contravariance, which makes more typical problems when generics are concerned. So, I searched for genetic syntax. The chapter "Inheritance" considers more trivial case, but it's important to know.

By all measures, this is a good article. That why I advised you to reference it in a separate answer. You could point out that my answer is only introductory and does not describe all the detail. I'll have corrected myself by adding a [EDIT] note to my answer. My initial statement was inaccurate. Thank you for correcting me.

—SA

[no name] 12-Mar-15 11:15am

Alright, done :-)

[no name] 11-Mar-15 22:08pm

Btw, writing the concept is tougher than expected, I guess I'm out of practise. Will ~10 pages in 12pt be okay?

Sergey Alexandrovich Kryukov 11-Mar-15 22:37pm

Yes.
—SA

manchanx · Answer 2 · 2015-03-12T05:14:00

Solution 3

Please see Sergey's answer for an excellent explanation of overloading and why it normally doesn't have anything to do with inheritance (derived classes). You'll be safe in 99% of all cases sticking to that.

In practice, there can be some edge cases where things aren't so clear (the other 1%) and one of those cases overlaps with inheritance. If you want to read up on that, please refer to C# in Depth - Overloading[^]. It's fairly advanced though and maybe you want to just bookmark it and come back to it once you've gathered a bit more experience :-)

Posted 12-Mar-15 5:14am

manchanx

Updated 12-Mar-15 5:39am

v2

Comments

Sergey Alexandrovich Kryukov 12-Mar-15 11:19am

You know that all the essence is often in the "other 1%", so, my 5. :-)
—SA

[no name] 12-Mar-15 11:25am

merci ;-)

Sergey Alexandrovich Kryukov 12-Mar-15 11:57am

Continued after plugging in the power source... :-) Wanted to add few lines:

If I designed C# and .NET, I would probably simplified these rules; they are not intuitively obvious enough. In what way? By generating compilation error in all cases when priorities of the interpretation are presently considered, and showing all possible matching alternatives for all cases when the call could be successfully done. Anyway, the user would always have a choice of using type case expression for any actual argument in question. After all, the whole "overloading" feature is nothing but syntax sugar.

It's hard to say for where the decision of using such less obvious choice come from, but I have an impression that it goes from the idea of "compile-time polymorphism", which looks like an illusion to me, or rather counter-productive conception to me. If the developers omits some detail of the definition or statement, such as in quite reasonable type inference, it does not mean that it can change the behavior of the software. It's nothing but shortcuts in the code, the style matter. And the certainty should not be sacrificed for the sake of "elegance" understood this way.

At the same time, polymorphism based on dynamic dispatch is extremely productive. It does not have to be based on virtual or interface methods/properties. Dynamic dispatch typical for scripting languages and based on simple name correspondence of the members is perfectly adequate to scripting approach.

Do you know how many people just on this site were confused by the closeness of the term "override" and the "term" (quotation marks intentional) "overload"? Mixing up between the dynamic and compile-time can be a deadly mix. If people did not coin any term for "overloading" (come to think about, it does not even require any separate term; we can just say "function name", "signature", etc.), the life of those beginners would be way easier. :-)

Cheers,
—SA

[no name] 12-Mar-15 13:05pm

I fully agree. While it would certainly lead to more verbose method names, maybe no "overloading" at all would have been the cleanest route. At the very least, they should have coined a better term for it.
Maybe a VS-Plugin that showed the signature of the method-overload chosen by the compiler as some kind of automatic code-annotation would make sense. Should be possible using Roslyn I guess.
- Sebastian

Sergey Alexandrovich Kryukov 12-Mar-15 13:47pm

I would rather advise the developers to avoid running into such complication, which is always possible by taking a bit of extra care. Demanding some improvements from Microsoft and ECMA/ISO would be much less realistic action... :-)
—SA

deepankarbhatnagar · Answer 3 · 2015-03-12T00:46:00

Solution 2

hi hope this will help you to solve your query.

http://stackoverflow.com/questions/16709065/overloading-base-method-in-derived-class[^]

Posted 12-Mar-15 0:46am

deepankarbhatnagar