ฝัง
- เผยแพร่เมื่อ 1 ต.ค. 2024
- The advantages of Composition over Inheritance
💬 Topics:
- What is Composition?
- What is Inheritance?
- Class-based vs Prototype-based Inheritance;
- Composition in Go;
- Inheritance in Kotlin;
- Classes vs Types vs Interfaces;
- Go Type Embeddings;
- Kotlin vs Go;
📖 Blog Article - www.awesome.cl...
🥇 Become a Member - / @awesome-coding
✉️ Join the Newsletter - newsletter.awe...
You can use "by" in Kotlin e.g.:
class CounterSet(
private val innerSet: MutableSet = mutableSetOf()
) : MutableSet by innerSet {
//only new and or overwrite func's
}
Nice video but I didn't enjoy the cognitive load of switching between languages (Java vs Go) and data models (shapes vs cars). Also, for me, not detailing composition cons and inheritance pros is a red flag. Personally, knowing when to use each method effectively makes me a better dev than fanboys trying to shoehorn composition into everything.
Noted! Thank you for pointing out these issues.
Clearly I'll have to do a better job next time.
Maybe learn a little more about inheritance before you start blabbering nonsense. The car, minivan and truck are subclasses of Vehicle. It's not the first two being a subclass of the last, or the first one being a subclass of the second.
In OOP dependency injection + composition. 😌😘👌🏻
You're throwing away 25% of OOP by doing that. Not saying it's a bad thing, but can it still be called OOP?
@@carlosmspkwhy not? A subset of c++ is still the same language :)
@@plaintext7288 C basic is not C++
I know over the years C++ changed to a point where it no longer is a superset of C, but even when it was, they were different languages.
Either way, you're talking about languages. I was talking about the core principles of OOP, if you throw one of them out the window, I'd argue it's no longer OOP
@@carlosmspk that’s not true my friend. Because OOP means objects sending messages, so is all objects. Even if the object is a composed object or a dependency object, still object talking to objects.
@@julian_handpan hah, you're coming from Smalltalk. Alright, makes sense, then
The cleanest implementation of composition I've come across is the one in Odin and Jai. They let you put a 'using' keyword in front of any field, variable, or namespace to make its members directly accessible in the current scope.
So not only can you use it in structs/classes, you can also use it in fuctions to essentially destructure the object or in namespaces to compose a larger API from smaller API subsets
If I understand correctly, what you're describing is very similar to the 'with' keyword in kotlin
@@ProfessorRS Had to look it up, but looks like it yeah! Except apparently *with* is a function in kotlin and not a keyword.
If you could do 'with var app = makeApp()' it would basically be equivalent for the function use case
“Composition over inheritance” is what a lot of beginners tend to say. Which to use depends entirely on the use case and design pattern.
composition makes you happy 🙂
the inheritance, only when your parents were millionaires and considerate
I really need some millionaire parents 😅
@@awesome-coding well, composing them will probably be possible in the future(?
@@dei8bit haha!
Not sure why we switched over to Go to demo composition, when the same could've been done in Java (OOP languages) but that's beside the point.
These arguments oftentimes glorify composition as if it doesn't have any downsides when compared. Inheritance (Pros: Reusability, Polymorphism, Code organization | Cons: Tight coupling, Fragility, Inflexibility), Composition (Pros: Flexibility, Loose coupling, Code reuse | Cons: Complexity, Overhead (Memory), Code organization).
Inheritance should be used when there is a direct class relationship whilst composition should be used when there is a need for more dynamic behavior via loose class coupling.
Hey!
I'm not sure why composition would require more memory overhead? We are talking about the same data being stored in the memory, right?
I switched to Go for two reasons:
1. To bring on the argument that some languages don't allow inheritance at all since the language designers felt like the cons outweigh the pros.
2. I really like the inner type promotion aspect of Go, and I believed it would be an interesting detail when it comes to different ways in which software could be written.
But to your point, yes, you are right, composition can be achieved in any OOP languages as well.
@@awesome-coding you also added the disclaimer that this is a segment called "The Snippet", but I'd argue it doesn't work very well. If you're trying to explain a concept and change languages midway two things happen:
1-Any viewer not familiar with one of the languages will have trouble understanding that part
2-Even viewers that are familiar with both languages, will have some mental burden to see the conceptual differences of what you're trying to show, because the actual differences from the language itself (syntax, strucutre, etc.) will be extremely noticeable.
I understand the idea of having multiple languages to kind make the concept come accross in a more "pure", language-agnostic form, but I don't think it works very well. Just my 2 cents.
@@carlosmspk Hey! I really appreciate your feedback, and I actually believe you are right on this one. The context switching between languages makes things harder to follow along. I'm still exploring and testing this "The Snippet" concept, so your feedback is very valuable. Thank you!
@@awesome-coding As someone who didn't know the first language and is only vaguely familiar with GO, I wanted to tell you that you did just fine and it was understandable. I think the only sticking point is that the viewer needs to understand how GO doesn't use a keyword for explicitly stating the association of methods to structs - though you did state it if they don't 'get' it then the rest of the explanation could be lost.
@@kevinb1594 Thank you for your input!
Great video! I’m teaching my self rust coming from typescript and this makes traits much more clear.
Glad to hear!
No wonder Go is trending so hard! Amazing video as always mate!
Glad you liked it!
Great video 👏
damn the languages are hard
Which one?
@@awesome-coding which one is not ?😅 just kidding bro
@@VigneshwarDev 😅
Ok, got it. Now spit out the cons of Cumposition. The memory overhead, complexity etc...
Hmm I'm not sure why people are mentioning memory overhead in this scenario. Are talking about the references to the type embeddings? I'm pretty sure that's highly optimised.
When it comes to complexity, the same argument can be made about Inheritace.
As I said, Inheritance is not bad, it just has very specific use-cases, and is not a good idea to always use it when code reusability is required.
never used java before, but for some reason i always assumed that composition wasn't even a thing in java. obviously it's just a pattern but i've never seen it before in java and it has a reputation of being _the_ oop language. i associate inheritance with oop more than i do with composition.
Yep exactly! This is the miss conception in OOP, because the OOP principles are usually enforced.
Unrelated: OOP in JS is so disgusting.
fact!
Js in general is disgusting
Or just use interfaces
Right... but languages don't allow state in interfaces most of the time so how would you reuse state?
🔥🔥🔥
let's goooooo
✌️✌️✌️
May not be the first but heyy 2nd!
May not be the first but heyy 2nd!
👍👏🏻