Lecture thumbnail 0:00 / 0:00 One of the things which I find most disappointing in both the Java and Dotnet ecosystems is the lack
of multiple inheritance, which is sometimes very useful.
Let me show you some of the problems that you end up encountering if you try to emulate multiple inheritance
and this is in fact the implementation of the decorator pattern because that’s what you end up doing.
So let’s suppose that you have a class called Bird.
Now a bird can fly.
So we can make a method called fly.
And here I’m just going to write line soaring in the sky.
Okay?
So we can also have a class called Lizard and you can see where this is going.
So the lizard class will have a method called crawl and we’re going to write line crawling in the dirt.
Okay, So we now want to make a dragon, which is both a bird and a lizard, and it would make sense
to inherit from both of these classes.
Unfortunately, we cannot.
We cannot make a dragon which inherits from both bird and lizard because we can only have one parent
class.
Certainly simplifies things for language designers, but makes things more difficult for us in the real
world.
So how do you implement the traits of both Bird and Lizard in Dragon?
And the answer is, Well, of course you use the decorator pattern and you extract the interfaces.
So you start using interfaces and here we can extract the interface from bird.
So here we get this pop up, we get to specify which members we want in the interface.
So I want the fly method, for example.
And similarly we can go into the lizard and we can extract the interface here as well.
So here we take the crow method and we put it into I Lizard.
So having made these two interfaces, what we now do is we say that a dragon is both a bird and I lizard
at the same time.
And now the question is, well, how do you implement these methods?
How do you implement crawl?
How do you implement fly?
Do you want to just replicate?
I mean, one option would be just to cut and paste everything.
So you simply take the entire method and you paste it in here and you do the same for the lizard and
you assume that this is okay.
Unfortunately, you want to make changes in only a single location.
It’s kind of like the single responsibility principle in a way, in the sense that you only want one
location where something is changed.
You don’t want to change the behavior of flying in both bird and dragon unless in fact they fly in some
sort of different ways, which is quite possible.
So how do you implement this?
Well, one of the ways is you simply keep both a bird and a lizard as members of Dragon.
So you have something like bird, bird, lizard, lizard.
And then of course, you need to initialize them somewhere.
So typically, I mean, if you’re using a dependency injection framework, you would of course make
make a constructor which just initializes all the fields.
Or of course, if you wanted to just do a demo like I’m doing, you can get away from all of this and
just use the sort of initializes in place here.
And this is also very easy.
Whatever choice you make, you need to implement the interfaces of I bird and I lizard and you need
to proxy them over.
You need to forward them to the appropriate types.
So the way this is done using Resharper is you open up the generate menu and you choose delegating members
and then you get to select all the members you want to delegate, which in our case is everything.
So I’ll just press return here and here is what we get.
So we automatically implemented both I bird and I lizard by implementing the appropriate parts of the
interface.
So now we have a method called crawl and a method called fly.
And these just get sent over to Lizard Crawl and Bird Fly so we can try using this.
So here I can say for D equals new dragon.
And here for example, I can fly, Dragon can fly and dragon can crawl like so.
And if I execute this well, hopefully we get the right output, the output with us both flying as well
as crawling, using the bird and lizard class respectively.
Hooray, everything works.
Okay, so this is a very simple example.
And typically the multiple inheritance which is done using this approach can hit a rock when you have
certain other issues.
Like let me give you an example.
Let’s suppose that both Bird as well as Lizard implement some sort of property and we’re going to try
this diamond inheritance problem that you have in C plus plus what if both of the base classes implement
the same thing?
So both a bird and a lizard have a wait?
So I’m just going to have it as a property.
So we have weight here and we have weight here.
There we go.
Okay, so now what we want is we want these weight properties to be part of the interface.
So here we do pull members up and we select the weight like so.
And now it’s part of the interface here and we do the same for the bird.
So once again we go and we pull members up, press return and now weight is part of AI, bird and lizard.
But this this leads to an interesting problem.
We now have sort of two implementations of the same thing.
So if I go alt enter and I implement the missing members, you can see the weight is shown here twice.
And if I press finish like so, then we get explicit implementations.
So we get an explicit AI lizard weight and I bird dot weight as well.
Of course, the real question is what do you put in the getter and the setter?
Because you might assume that a correct weight is required in order for a bird to fly and a lizard to
crawl.
You need the correct weight measurements to be able to perform those operations, which means that you
have to have a way of setting this.
On the other hand, what becomes really creepy is what does it mean to say dot weight equals so and
so?
Notice that it’s highlighted in red here cannot access private property weight.
Now why is the property private?
Did we really make it private?
And if we make it public here and if we make it public here as well, that’s not really going to help
much notice that the modifier public is not valid for explicit interface implementation.
So you cannot even have this property.
So the way you would typically do this and this is quite creepy, is you would implement the property
yourself.
So this is one of those cases where having something delegated for you isn’t good enough.
So you would have something like weight public int weight for example.
Now what you can do now is you can obviously set the weight and this actually satisfies the interface.
Amazingly enough, what you get to see is that weight right now is the correct, the correct sort of
tool for setting the weight internally.
Unfortunately, the setter is completely wrong because remember, we need the bird and the lizard to
have their own properties set correctly.
So how would you do those?
And the answer is, well, you would apply them in the setter.
But I just want to show you that we are using them so soaring in the sky with weight and then I’ll put
the formatting dollar here.
So with weight, weight and crawling in the dirt with weight and once again, I’ll put a weight in here.
So this is how we’re going to do it now.
And of course, if we now do this.
So if I set the weight, first of all, before I actually try to fly and crawl, then we’re going to
get the values of zero, of course, because we’ve only set the weight in the original Dragon.
That’s where we actually store it.
So in order to kind of fix all of this, what we do is we define the setter.
So first of all, you would go ahead and you would make a property with a backing field.
Now the getter is okay, we return the weight and the setter is almost okay in the sense that we set
the weight and that’s it.
But in addition, what we do is we say bird dot weight equals value and we say lizard dot weight is
also equal to this value.
And this way is the only way that you can actually get those methods operating correctly.
So as you can see, even though the interface based approach kind of works by using the decorator pattern,
it is a bit ugly.
Even with all the magic that Resharper brings to the table with auto generating the delegated members,
it’s still very inconvenient to work with.
Play Play Play Stop Play Play Play Play Play Start Play information alert