Compile-Time Polymorphism in C#. Object oriented programming is a rabbit… | by Rikam Palkar | May, 2022

Object oriented programming is a rabbit gap the place polymorphism is simply one other thread within the gap, let’s see how deep can it go.

Photograph by Thalia Tran on Unsplash

This text will take you on a journey to unravel the thriller of compile time polymorphism . Plus in C# we now have simply the precise materials to make it worse, with technique overloading and overriding, we even have the idea of technique hiding, which makes the entire concept of polymorphism a bit baffling. And that’s why I’m going to clear the confusion by breaking down the concept into 3 components.

This can be a sequence of three articles the place we’re going to take a deep dive into polymorphism. The next are the three items of the puzzle.

  1. Compile-time polymorphism
  2. Run-time polymorphism
  3. Methodology hiding/ shadowing

As a result of the compiler is aware of which technique to name at compile time primarily based on technique’s signature. This dependency is solved at compile time. Okay! this sounds good in principle however let’s see the way it works virtually.

HOLD ON SEC!!, what did you imply by technique signature, although?

Properly, there are 4 items to any technique.

  1. Methodology identify,
  2. Return kind,
  3. Parameter/s,
  4. The return kind
Itemizing 1: Methodology signature

There’s a big argument between the developer’s group, whether or not return kind needs to be a part of technique signature or not!!

How about we clear that confusion from Microsoft?

As per Microsoft, “A return kind of a technique is just not a part of the signature of the tactic for the needs of technique overloading. Nonetheless, it’s a part of the signature of the tactic when figuring out the compatibility between a delegate and the tactic that it factors to”.

In easy phrases, whereas “overriding a technique”, return kind is considered as part of technique signature.

whereas “overloading a technique”, it’s merely ignored.

Let’s perceive polymorphism step-by-step with precise coding and with coding examples we’ll be taught the behaviors to assist the argument above.

There are few guidelines you want to concentrate on whereas overloading a technique.

  1. Sort of parameters needs to be completely different, and the identify of the parameter doesn’t matter.
  2. Variety of parameters needs to be completely different.
  3. Order of the parameters needs to be completely different.
  4. Final however not the least, return-type, entry specifiers or any of different fancy key phrases corresponding to static, summary, sealed, digital aren’t considered.

To reveal these guidelines, I’m going to code following UML all through the article, this may contact upon nearly all of the facets of technique overloading.

Think about we’re designing a class superhero during which our activity is to customise a swimsuit. There could possibly be completely different arguments coming into play, shade of the swimsuit, kind of swimsuit, or whether or not the hero likes to put on his underwear out or not and so forth. Allow us to go forward and design a category to fulfil these factors.

Within the following code snippet, we’re designing a swimsuit for a “Superman”.

Itemizing 2: class SuperHero

This code works so long as you need your default superhero to-be superman. However let’s face the very fact, he ain’t that nice. So with the intention to customise a swimsuit for an additional superhero, we will create a separate technique CustomizeSuit().

Say I’ve typeOfSuit and I wish to customise that, it could possibly be a leather-based or a steel swimsuit. With a purpose to code this I can merely create a technique which is able to settle for one string kind parameter which might be typeOfSuit.

Itemizing 3: Methodology CustomizeSuit with one parameter

Rule #1: Sort of parameter/s needs to be completely different, the identify of the parameter/s doesn’t matter.

My superhero expresses an curiosity in a steel swimsuit, now he clearly can’t put on underwear on the highest of it. So I can merely overload the CustomizeSuit() technique to just accept completely different kind of parameter. In right here, we’re overloading a technique which accepts boolean kind, if the worth of this parameter true then our hero goes to put on an underwear exterior else inside.

Itemizing 3: Overloaded technique CustomizeSuit with boolean parameter

Rule #2: Variety of parameters needs to be completely different.

Some customers wish to both desires to customise the kind of swimsuit or determine the position of the underwear however others is perhaps thinking about altering each collectively. We will obtain this just by overloading a technique with a distinct variety of parameters.

Itemizing 4: Overloaded technique CustomizeSuit with 2 parameters string and boolean

Rule #3: Order of the parameters needs to be completely different.

You possibly can have the identical variety of parameters however the order should be completely different, for instance I can take code from itemizing 4 and do that.

Itemizing 5: Overloaded technique CustomizeSuit with 2 parameters boolean and string

Itemizing 5 clarification: I simply interchange the order of parameters in itemizing 5. Compiler seems for the index of the parameter and its kind. If Sort is completely different at identical index then it’s a sound overloaded technique.

One other variation could possibly be as itemizing 6

Itemizing 6: Overloaded technique CustomizeSuit with 2 parameters string and string

Rule #4: Final however not the least , return kind, entry specifiers or any of different fancy key phrases corresponding to static, summary, sealed, digital means nothing.

Let’s go absolutely wild on that one, lets?

Rule #4.1: Return kind is just not considered.

Within the following instance all the pieces is similar between 2 strategies, besides the return-type. In case you have 2 strategies with the identical signature however completely different return-type, it isn’t thought of as technique overloading. Compiler will throw a compile-time exception.

Itemizing 7: Overloaded technique CustomizeSuit with identical signature however completely different return varieties

The Exception: Sort ‘SuperHero’ already defines a member known as ‘CustomizeSuit’ with the identical parameter varieties.

Picture 1: Snapshot of exception the place return varieties are being ignored

Rule #4.2: Entry specifiers are ignored

Properly rule 4.1 was fairly cool, Now for rule quantity 4.2, we have to change the entry specifiers.

Itemizing 8: Overloaded technique CustomizeSuit with identical signature however completely different entry specifier

Identical good exception!!

Picture 2: Snapshot of exception the place entry specifiers are being ignored

Rule #4.3: Particular key phrases are ignored

Within the following snap you’ll see, not one of the key phrases are working with an overloaded technique. So adorning a technique with these key phrases means nothing to the idea of overloading.

Word: For the summary technique, I’ve marked class as summary.

Picture 3: Few examples with completely different decorators on technique CustomizeSuit

Above all strategies falls below the identical exception.

Sort ‘SuperHero’ already defines a member known as ‘CustomizeSuit’ with the identical parameter varieties

Picture 4: Compile time exceptions

We now have come a good distance with technique overloading, there’s another vital idea I wish to throw in there as a bonus level.

The next code snippet is a mum or dad class SuperHero. It comprises each overloaded technique that we’ve mentioned to this point.

Itemizing 9: class SuperHero with 4 overloaded strategies

Let’s create a toddler class which is able to inherit the mum or dad class SuperHero

Following class IronMan is the kid of class SuperHero. which may be very elegantly overloading a CustomizeSuit() technique with 3 parameters.

Itemizing 10: class IronMan with 1 overloaded technique

Yeah!! You heard it proper, technique overloading is just not restricted inside a identical class.

I’ve created an occasion of each mum or dad and a toddler class. Take a look on the following picture 5, I get 4 overloaded strategies with mum or dad’s object.

Picture 5: Dad or mum’s object exhibiting variety of overloaded technique CustomizeSuit

Let’s see what quantity we get once we attempt to name CustomizeSuit() with a toddler’s object. As you possibly can see within the picture 6, baby class A.Okay.A. IronMan has another further depend, which is referring to the tactic we simply created in itemizing 10. Therefore proved, you possibly can really overload a technique from completely different courses.

Picture 6: Little one’s object exhibiting a quantity overloaded technique CustomizeSuit

Though I can overload a mum or dad’s technique in a toddler class, nonetheless there’s one factor we should always concentrate on.

Word: The 4 guidelines that I discussed above are solely relevant throughout the identical class.

Let’s not get confused right here! Let me reveal this with an instance. Take a look on the following two photos 7 and eight.

Within the picture under, the CustomizeSuit() technique is outlined in class SuperHero and the identical technique is once more outlined in class IronMan and it appears the compiler has no drawback with it.

Object of class SuperHero will name the it’s personal model of CustomizeSuit() technique, and object of class IronMan would have further depend overloaded technique however it’s going to nonetheless name its personal implementation of CustomizeSuit() technique.

So level being, you possibly can have the identical signature of an overloaded technique solely if you’re in a distinct kind.

Picture 7: Two courses have strategies with identical signatures

However you possibly can’t have the identical signature throughout the identical kind.

Look, how compiler reacts in picture 8. It provides me an error when I’m overloading a technique with the identical signature throughout the identical class. So keep in mind these 4 guidelines are relevant throughout the identical class.

Picture 8: Methodology with identical signature is outlined in the identical kind

Sure, Methodology overloading could possibly be fairly overwhelming, once we attempt to cowl all the chances however upon getting the fundamentals fundamentals clear it is possible for you to to know its goal in object oriented programming. On this article we deep dived masking all facets with completely different examples to know what is suitable and what’s not in relation to compile time polymorphism.

Need to Join?Hit me up on LinkedIn.

More Posts