Go lang is statically typed and it does allow for implicit interfaces. It''s because Kotlin is statically typed using a nominative type system. This is why it why you need to explicitly specify the relation.
Thanks Robert - that's a great clarification... it's not just the static typing. TIL Go is structurally typed! Might have to play with that at some point 👍
Go and Typescript are both structurally typed and Kotlin uses a nominal type system, but all of them are statically typed. This is something people rarely talk about, maybe a video about it would be nice!
Hey Moamen! Man, thank you so much for the SuperThanks! I'm excited about growing the channel and the community - and your support is a big encouragement!
Dave, just want you to know I love your content and I actually following these to catch up with new Kotlin & Android knowledge, please keep up the good work.
I gotta say I'm kinda jealous of the newcomers who are getting into programming / computer science today. Only ten years ago this quality in a lesson was not available to me on YT or similar platforms ~FOR FREE~. Big up for the outstanding video!
There's a mistake in Chapter 13 in the Waiter's UML box: Waiter+ + prepareEntree(name: Entree): Entree? Should be: + prepareEntree(name: String): Entree?
So for proxy classes or to implement the proxy object pattern I can't use the class delegation, one has to manually forward every function call to whatever is the current proxy implementation. 😢
In the example at 9:05, it's important to note that raceCar2 isn't a Junker; it's a RaceCar that wraps a Junker (line 36). It delegates speed and accelerate() to the Junker (lines 27-28), but it provides its own implementation of makeEngineSound() (line 29). This is roughly the same idea as if RaceCar were to inherit from Junker and override only makeEngineSound().
About the ackwardness of IVehicle and Vehicle. It's pretty obvious here why this naming is suboptimal. All of the cars are Vehicles. Yet the thing called Vehicle is just one example of a vehicle. Why is that one called a Vehicle but not the others? The interface should be called Vehicle and this Base subclass should get a name fitting your domain. Since this is just an example you might end up with a name like BaseVehicle but in a well defined domain this would have a better name.
Hey, thanks for commenting! Yes, it can look unnatural - mostly because it's easiest for us to map our notions of real-world object relationships onto software models - for example, RaceCar "is a" Vehicle, and Vehicle "has a(n)" engine. Many of us learned that kind of mapping early on, and plenty of successful software systems have been largely designed around it. It's helpful because one of the most important characteristics of code is for a human to readily understand it. That shouldn't be our only lens, though. There are additional characteristics (flexibility, performance, scalability, security, etc.) that we should consider, and to understand those, we have to ask what it is that we gain or lose by constructing the relationships one way compared to another (e.g., inheritance vs. composition, recursion vs. iteration, and so on). That's what I hoped to achieve in this video - to demonstrate that inheritance can also be expressed with object composition or class delegation, and to consider the trade-offs involved with each approach.
Dave I love your videos and out of the millions out there , your way of explaining things stands out .
Please keep them coming
That's very kind of you to say - thank you so much! I'll keep at it!
At last! patterns starting to emerge in the channel. Thank you so much! 😊
Hey, you're most welcome! I'm glad you mentioned it last time - there were enough likes on those comments that I couldn't ignore it! 😁
😊❤
Go lang is statically typed and it does allow for implicit interfaces. It''s because Kotlin is statically typed using a nominative type system. This is why it why you need to explicitly specify the relation.
Thanks Robert - that's a great clarification... it's not just the static typing. TIL Go is structurally typed! Might have to play with that at some point 👍
Go and Typescript are both structurally typed and Kotlin uses a nominal type system, but all of them are statically typed. This is something people rarely talk about, maybe a video about it would be nice!
Thanks
Hey Moamen! Man, thank you so much for the SuperThanks! I'm excited about growing the channel and the community - and your support is a big encouragement!
Dave, just want you to know I love your content and I actually following these to catch up with new Kotlin & Android knowledge, please keep up the good work.
Hey, thanks so much, Nhat Tan - I appreciate your kind words! I'll keep at it!
I gotta say I'm kinda jealous of the newcomers who are getting into programming / computer science today.
Only ten years ago this quality in a lesson was not available to me on YT or similar platforms ~FOR FREE~.
Big up for the outstanding video!
Yes, it's quite a different world, for sure! I'm honored (and encouraged!) that you found this lesson to be of that level of quality!
Thanks Dave! Your Kotlin content is Gold.
Thanks so much, GB! I'm glad you're enjoying it! 🎉
Pros and cons over dogmatics, thank you!
The 'by' keyword in Kotlin is indeed one of their great syntax sugars.
This is the best explanation to this principle I have ever seen, thanks!!!
There's a mistake in Chapter 13 in the Waiter's UML box:
Waiter+
+ prepareEntree(name: Entree): Entree?
Should be:
+ prepareEntree(name: String): Entree?
Thanks, Eugene! I'll get that fixed up. 👍
Thank you, Dave! Superb video as always. Keep them coming! :)
So for proxy classes or to implement the proxy object pattern I can't use the class delegation, one has to manually forward every function call to whatever is the current proxy implementation. 😢
Very nice explanation. Thank you
So, with *this* kind of composition, we have one vehicle inside another vehicle?
Crispy clean explanation
Just bought the book, was gonna get it eventually but this one sold me, great vid!
Hey, thank you so much! I hope you enjoy the book! 🙂
Dave, may I know the name of font you used?
Hello! Are you referring to the font on the thumbnail image? If so, it's called Luckiest Guy: fonts.google.com/specimen/Luckiest+Guy
@@typealias Sorry, I meant font using in the IDE.
Ah, yes - that's using JetBrains Mono: www.jetbrains.com/lp/mono/
No one explains anything better than Dave, omg.
if Junker has 'makeEngineSound() = Unit', why it printed "Vroom! Vroom!" ? while 'accelerate() = Unit' returned speed as 0.0
In the example at 9:05, it's important to note that raceCar2 isn't a Junker; it's a RaceCar that wraps a Junker (line 36). It delegates speed and accelerate() to the Junker (lines 27-28), but it provides its own implementation of makeEngineSound() (line 29). This is roughly the same idea as if RaceCar were to inherit from Junker and override only makeEngineSound().
@@typealias Oh! I get it now! Thanks for your kindness to explain!
🎉 That's great! Happy to do so!
About the ackwardness of IVehicle and Vehicle. It's pretty obvious here why this naming is suboptimal. All of the cars are Vehicles. Yet the thing called Vehicle is just one example of a vehicle. Why is that one called a Vehicle but not the others?
The interface should be called Vehicle and this Base subclass should get a name fitting your domain. Since this is just an example you might end up with a name like BaseVehicle but in a well defined domain this would have a better name.
why not just call the interface Drivable, since thats the point of it?
As always excellent
Thanks so much, Mohammad!
Great as usual. Thanks Dave :)
Thanks so much!
It would be much nicer to have engine in composition. This kind of composition looks too unnatural
Yes! I wanted to write that comment too.
Hey, thanks for commenting! Yes, it can look unnatural - mostly because it's easiest for us to map our notions of real-world object relationships onto software models - for example, RaceCar "is a" Vehicle, and Vehicle "has a(n)" engine. Many of us learned that kind of mapping early on, and plenty of successful software systems have been largely designed around it. It's helpful because one of the most important characteristics of code is for a human to readily understand it.
That shouldn't be our only lens, though. There are additional characteristics (flexibility, performance, scalability, security, etc.) that we should consider, and to understand those, we have to ask what it is that we gain or lose by constructing the relationships one way compared to another (e.g., inheritance vs. composition, recursion vs. iteration, and so on). That's what I hoped to achieve in this video - to demonstrate that inheritance can also be expressed with object composition or class delegation, and to consider the trade-offs involved with each approach.
we in 1990s?
I