07:03 "Inheritance encourages you to build this taxonomy of objects very early on in the project. And you are most likely going to make big design mistakes while doing that. Because humans cannot predict the future." "I think it's just better to use composition from the start. It's more flexible, it's more powerful, and it's really easy to do."
This is my number one problem in every single project I do. This is coming from someone who always developed in a class oop style, and now changing is so much more difficult because I am so used to what I used to do. However, I agree 100% that it is better in most scenarios, the only scenario that I would use a inheritance over composition is when I am writing a base class and I want to enforce implementation of an abstract behaviour that all objects in future must have.
@@hugodsa89 So for example you make a base composition that the real compositions have to inherit? like returning the name or type of the composit and some sort of copy function or how to get the 'real' 'raw' data so you can leave that in an array with all other composite data of the same type in sequential memory. I think something the Video has not mentioned is the fragmentation of OOP data. If you want to update all poop states of all Animals then it makes no sense to jump through multiple pointers to get to the data. This would just give you cash misses and make your program slow. If you keep all position data in one sequential memory your cpu will chew right through it. Loading sequential memory can be 100x faster. Nothing beats an array.
@@hugodsa89 I completely agree. The only time I use inheritance-type pattern is writing interfaces/abstract base classes, but even there it's not inheritance but enforcing implementation as you say.
Spread operators are not just sugar for Object.assign. Object.assign mutates the given object, thus may trigger object setters while spread operator creates a brand new iterable making it more useful with immutable techniques.
I really love how extremely simple your example are presented! it really makes me roll my eyes when "beginner" guides use long-winded examples where you have to think about a thousand things at the same time and get confused and lost in concepts unrelated to what you're actually trying to learn.
Inheritance is appropriate for single-level abstract classes where you define expectations of abstract methods that MUST be defined in a subclass. You effectively have written a API-contract. In almost all other cases, I favor composition. I love your videos and the style of teaching [often] techno-jargon.
I blame the overuse of inheritance on college focusing too much on OOP and training us to overuse that pattern, and cram inheritance into our projects. A perfect inheritance hierarchy is a wonderful thing that gives you a sense of structure and a mental model. But it's not feasible in today's agile world cause it's unmaintanable. Most agile projects would benefit from using composition.
Exactly! There are very rare situation where we would like to use inheritance, this idea should nailed in very narrow scenario that can be thinked as undividable unit, though should be inherited. For example of how the barker is barking actually.
What is presented in the video *is* actually *(multiple)* inheritance. See the discussion here: www.reddit.com/r/programming/comments/5dxq6i/composition_over_inheritance/da8bplv
@@PHILOSOPHYALPHAMALE Still is in many places and the dynamic is the same if they teach C# instead. It kind of feels very anachronistic that they still have such a heavy emphasis on OOP as if it's the end all be all of programming.
07:03 turning point of my perception of programming in general I always found it hard to implement inheritance in real world applications but still used it thinking that's how I was taught oop and that's how I'm suppose to write programs thanks a lot for such a great video
MPJME - I've been a developer for almost 20 years. I've developed in multiple languages - COBOL, ActionScript, Objective C, Java, JavaScript, PHP, etc. I feel like I've always been "behind the curve", because I've had to learn so many languages (frequently starting over). I just discovered your channel last week, and I've been binge watching, because I have learned a LOT from them. You are filling in the pieces that I've been missing from being a "self-taught" developer. I feel like I'm now becoming the top-notch developer that I've always wanted to be. THANK YOU!!!
This is a nice explanation. What you consider "composition" is however called "concatenative inheritance". Composition is achieved by passing more specialized components into a more general one. By doing so, you create an object model tree in which objects reference and use other objects rather than making a type tree (taxanomy) in which objects are tightly coupled to their parents (prototypal delegates or parent classes) as opposed to loose coupling in case of composition.
Exactly! The video misunderstands the term composition, which is actually a delegation of implementation to a delegate object contained within a bigger object (has a).
Host has been replaced by elevator music! I am in love! I will watch every single one of your videos! Next to being funny, you are a great teacher. To the point, so simple, no bs. Thank you!
I just have to say: You give the best example of WHY composition should be favored that I've ever seen. Anytime someone asks me, or this topic comes up; I immediately link them to your video. You explain so much better than I ever could. Thanks for that!
hell the first few lines were enough to put it in place. i found you after15 plus videos and yours was the only one who truly explained the difference in how to use them directly while thinking sanks
The amount of time saved by my brain trying to figure out how to adapt classes for abstraction. I've just switched back to more of a functional paradigm from OOP, and it's quite refreshing. Composition for the win.
I am a front end developer working in NYC. I really enjoy your explanations and have been watching your videos and coding up all the examples. I really enjoy both your explanations and when you have live coding examples. If you had a paid course I would surely purchase it. Thanks for creating this channel!
It's interesting, I often use both, when I know the inhereted functions will never change. Or they themselves are generics/Utility. Best of both words!
One video and I am an ardent fan!!!!! How amazing is this explanation!!! I kept viewing this link over and over again both here as well as medium.com but never actually spent these 8-9 minutes for some reason and kept myself so confused on this topic!!!! For the first time I am so clear as to why most experienced programmers favor composition!
After reading a bunch of articles about this topic, I have to say you really show why composition is better in most if not all cases without over complicating things. The way you explain it deliberately and with simple language really helped me understand just what exactly composition is! I have definitely found myself in past projects saying, Well I already made this class, if I break it up or even remove it entirely then the whole program falls apart. Going forward I'm going to be more wary of this.
I had a dream about trying to flesh out a new program with inheritance. I woke up sweating. That's totally true. Man this video was great. I watched quite a few of your vids now, you crack me up.
I'm working on transitioning many years of C++ experience into Javascript for a new job and I just wanted to say that your videos have been a great tool to help me figure out the common standards and concepts (as well as helping me prioritize what, exactly, is worth learning in this crazy-ass, over-complicated language lol). There aren't a ton of educational videos that are entertaining and well-produced, but yours manage to be both.
I'd LOVE it if you gave sample "tasks" for us to do to test ourselves. it sounds suspiciously like homework but it's the only way I could ever confirm I understood anything. haha
yeah it doesn't have to be anything super complex or detailed. maybe just like a brainteaser or something to think about and try till the next week. :) thanks for responding!
+Anthony Chung It's a bizarrely good idea, I think. Especially fronting it as a "brainteaser". It would also be a interesting success metric for the video - i.e. how many was excited by the video enough to try their hand at the brainteaser, and how many understood the video well enough to solve it. I'm not commiting to doing this yet because I like to let idea mull over for a few weeks before doing them, but I really like this concept intuitively.
+mpjme personally, i dont care for it. your videos are enlightening enough where i wouldnt ever feel the need for an exercise. however, i do feel like a github gist for each video would be appropriate
Your videos are awesome for many reasons, but to me, the best thing is that you aways come up with the "But.....". Thanks man, and continue with this great work.
programmers always leave the best comments, I actually read through the comments below and was not disappointed by trolling. I ACTUALLY learned something from other peoples experiences ahahah
For me, a great pivotal point in understanding composition over inheritance was (surprise surprise) a move from BEM to Tailwind. It just proved itself so much more powerful when you can compose your interface from utility classes rather than writing inherited Block Element Modifier rules
You are a genius good sir. This is gold! Funniest, simplest, most bestest articulated video thing on software design I have seen to date. Thanks! Keep em coming!
You know that scene in The Office when Michael says, ok now explain it to me like I'm a 5 year old. Well, I feel like you just did that and it worked perfectly. I'm not learning Java but the two concepts flowed into my brain immediately and easily from this tutorial. Simple and effective, and entertaining delivery. Liked!
Wow, that is a great video. I am a huge fan of prototypal inheritance but in less than 9 minutes you just convinced me that composition outperforms the whole concept of inheritance. But then I took some time to think about it, and I found some good parts to inheritance: 1) built-in objects in JavaScript have a huge list of properties and methods, that are spread over a prototype hierarchy like HTMLDocument > Node > Object. This hierarchy can trap you, but also help to separate layers of functionalities. So you can easily iterate on an object's properties without having to deal with all the methods inherited from Object.prototype like toString, constructor etc... 2) with composition, everything is _flat_, which can be a good thing at first look but can lead to overly complex objects (document.body has a total of 252 properties for example) 3) it is easy to extend a method behaviour with inheritance: you just override the function and call super() or equivalent. composing makes things quite harder : if I need to change the bark method of my RobotDog to bark(){ barker.bark("with a robot voice") }, I cannot compose it with barker. I would have to manually assign a bark method which instantiates a barker, call the original bark method in the context of the the RobotDog object, then add the extended behaviour, and things just became much more complicated. What are you thoughts on this ? Anyway, great video, you rocks !
+mpjme Or rather, not iterating over all properties without hitting the parent properties, but the only reason that you need to do that in the first place is because objects contain a bunch of crap that you're not interested in.
2. Composed objects don't necessarily have to be flat (even though they are in my simple example) you can hide inner objects inside composed objects and only expose things that you need on the outer API surface area. Document body is that big BECAUSE it uses inheritance - that is the problem with inheritance, you get an enormous amount of functionality that you don't need. 3. Again, just hide the inner implementation inside your composed object.
+mpjme But if you hide inner objects in composed objects closures, there are no longer exposed to user ? I think the assumption "objects contain a bunch of crap" is a bit simplistic
You hide the things you want hidden. If you need something to not be hidden you just expose it. You could also expose the inner object as a property. That way, you'd get even more granularity than an inheritance model.
I've just stumbled upon this video searching composition vs. inheritance for C# to take a second point of view as it was still unclear after watching a lesson from a course on Udemy. Your funny and practical approach was so clear and enlightening that instantly earned both my like and subscription. Thanks for taking your time to share it with lost travelers (:
came from the odin project. can't remember if it was linked directly there or if this was linked in an article they had me read. I love your energy and you explained this in a way where somebody who's struggling came away knowing more than I did. thanks so much.
With a statically typed language, inheritance is great for extension. I almost never use it for defining domain concepts, more for elegantly tapping into the language - a workaround :D
Great video! I've just read 100 pages on inheritance in "Secret of the JavaScript Ninja" by John Resig and I had so many doubts about going this route and now I have an alternative to explore. Thank you so much!
Man this is such a fantastic vid. Thanks for the wisdom. Inheritance seems like such a natural way to think about things. (I was introduced to classes via Django) but I have faced the exact problem you defined above. Must rethink object construction using composition.
I love how you described the problem of composition vs inheritance. From my experience, i see inheritance as powerful tool how the small tool-set, or a feature, that has been developed. Small enough that a structure can be reorganized, and inheritance rethink-ed again. Usually like up 2 or 3 levels, but possibly no limitation if this hole deepness is predictable from code design. So to be more specific. Pure composition says that there are used, and those who use. Only 2.. Master and the slave. If we think about inheritance we have a common behavior for all set of parent->child->...->child and those can be used as object of 1st level only. From this given example are only for showing the benefit of composition. Benefit from inheritors is all about how Barker barks, or meower "meows", where the inheritance will be a better choice. Thank you!
Thanks for your videos, they are amazing. After watching the video I didn´t know how to change the state, if it needs to be changed. I put my fingers in movement and I found two approaches: 1st, use a setter: const barker = (state) =>({ bark: () => console.log(state.sound) }) const setter = (state) =>({ set: (key,prop) => { state[key] = prop } }) const dog = (name) => { let state = { name, sound: "woof" } return Object.assign( {}, barker(state), setter(state) ) } let rufus = dog("rufus") rufus.set("sound", "I'm rufus") rufus.bark() // I'm rufus 2nd, use state to create the object: const dog = (name) => { let state = { name, sound: "woof" } return Object.assign( state, barker(state) ) } let rufus = dog("rufus") rufus.sound = "I'm rufus" rufus.bark() //I'm rufus Which approach you think is better? Thanks in advance.
BEAUTIFUL. thanks so much for the easier description. I have been hearing about it but, let's be honest, a lot of the resources befuddle their explanation to a bunch of terms and I personally learn better with examples. So thank you. I actually started learning OOP in college, so it is pretty hard wired into my mind until the job I'm in which they dont' want OOP... I never understood why until I started reading about this recently.
Absolutely love your show, I think your show is so beneficial (and fun and interesting and awesome etc...) not just because of your skills as a programmer, but also your ability to *keep things simple* in your explanations! Often people explaining things like to over complicate things to "sound smarter".... not fun at all. Please keep it up!!!!
I started understand behavioral composition is more powerful than inheritance via concept...thank you for your easy-to-understand video! Appreciated sharing your opinion, learn something new about JS! :)
The way I learned the is/has distinction isn't as composition vs. inheritance (where it really makes no sense, as you said), but rather as how you decide whether something should be a subclass (which can be done via composition or inheritance) or a member object. I see inheritance as an attempt to port over a concept from languages where it makes sense (more strongly typed languages make composition much more difficult if not impossible) to a language that doesn't really need it.
im going to use this as the bases for my future programming, after going down a rabbit hole of inheritance, fake classes, i keep hearing about all the problems associated with "this" and how the paths can be convoluted, even for me to understand watching the examples it becomes almost impossible to follow the path
I like the focus on what objects *do* versus what they *are.* This is a good example of a shift from one pattern to another. However, it relies on an unknown object (called "state") for the factory function pattern, and might make it more difficult to understand how the composition example maps onto the inheritance-based design. So, firstly, you'll still need an interface or a type for the "state" object passed into the factory functions -- in this case, it must have "position" and "speed" attributes for the drive method of "driver" to work. Secondly, if "barker" relied on any additional attributes, you would need to ensure the state object implemented those. This leaves you with the need for additional interfaces (which themseleves may or may not use inheritance for other reasons).
I agree with Antony Chung. Some sample tasks would be greatly appreciated. I am new to coding and find it difficult to find tasks that might further my understanding of the more complex concepts. Thanks!
This is so funny, I am using composition strategy it in solidity and it works perfectly. The mechanism there are modifiers, they also grant permissions as well.
I've been taught in college the inheritance concept as one of the core concepts for OOP. Inheritance is widely used, now and then one will encounter it. The composition concept is much more flexible and maintainable, though. I'd rather implement composition, but I think it is important to know the inheritance syntax.
9 років тому+1
I especially like this video! Very exciting to learn about composition :) Really thankful for your videos, they are informative without being boring, and tells me just enough about a topic to get me excited about diving deeper into it. Would be nice to hear about some more ES6 goodies that I should be using!
You speak to me from the soul, as always. Great video. Composition outperforms prototypal Inheritance not only in simpler structure but also in better readability due to the fact, that you don't have to use that f.....g "this" anymore. Sadly I can't come to this years JS-Conf because some serious childbirth is going one here :). I'd love to have a chat with you there. Have Fun in Berlin!
Composition of capabilities is a very good design pattern. The new features makes it even more advantageous. // Shorthand property names (ES6) a=1; b={a}; // { a: 1 } As functional programming also employs composition it seems fitting to think like a composer rather than a geneticist.
I think I get where composition can keep things clean and strategic, but traits/mixins also seem like a way to effectively grant classes functionality without risking inheriting more than you need.
Even though I agree that it is easier to think of what an object "is doing" rather than what "it is", it is very easily doable with interfaces. In your example, I would have many interfaces (bark, poop, drive) and each class would implement the interfaces t needs.
8 років тому
+bobdudan Having classes that implement multiple interfaces actually is "composition" as described in the video. It's only when you start to share implementation details between the classes that you are in trouble. In simpler terms for Java programmers: "implements" is good and "extends" is bad.
I'm new to the concept of factory functions (well, JS in general) but I understand Object.prototype.someMethod as a way of creating methods or properties that an object can inherit. One of the major benefits as I understand it is that if you have your object inherit methods rather than instantiating objects with them it's more memory efficient. Using this concept of factories, and composition, are you getting the same benefits? If I create 10 murderRobotThingies, am I creating 10 objects each with their own method, or are they kind of inheriting the method, almost like I used the Obj.prototype pattern?
I've always felt that composition should be used when you want to share behaviour (driving, pooping, etc) and inheritance should be used when you want to differentiate/separate (Maybe has a Some vs None or the difference between a GuestUser vs AdminUser). It's also important to keep in mind that you can use both at the same time, they're not mutually exclusive. For instance, a GuestUser and an AdminUser might have common behaviours through composition, but differentiate in property values or have overridden functions.
first time seeing your video from a friend's referral, haha, you crack me up and it's interesting to see daily life example that you used to better illustrate the concept. thank you and I subscribed.
Brilliant video, loved the Robot Murder Dog made me laugh. It's very thought provoking and I love the idea of composition because you only get the functionality that you need over all the functionality you might need or just because some other children use that functionality I'm going to have to learn more about it.
this video is actually making me laugh my ass off dude I love it, super helpful too as I'm trying to learn why inheritance is generally considered outdated now!
At First.. I felt reluctant to watch the video with such Handsome Poster Image ( : Scarcastic :D ) But then... I am spellbound by the way you have conveyed such a concept with such innovative, indulging and entertaining way.. Kudos. Yo!! your video rocks. I ill subscribe and follow your Videos :) With love from India !
I love the idea of mix-and-match types, it's like the best of both worlds between Classes and Interfaces. However, wouldn't it be difficult in a larger scale app to keep track of which properties are in which classes? Say I wanted to add "barker" into the Object.assign - wouldn't I have to check ALL my other factories to make sure I'm not overwriting anything?
As soon as I started it he recomended the previous episode and as soon as I started the previous one he recomended the previous previous one and then previous previous previos one. I almost got into an infinte loop, but I terminated my inquiry ultinately.
I really appreciate your videos MPJ. I'm not working as a front end dev yet but I think these vids will get me there sooner rather than later. I also really enjoyed starting this video at 1:52 at 50% speed and seeing how drunk you sound :-).
I really loved the video and i end up here after follow the stamp project e all the discussion over composition after the react release. I would like some tips, or even a sequence video for this one, on how to organize projects where the developers use composition. In my OO or MVC projects this is really straightforward but now with composition i am ending up with a huge helpers and functions directory witch doesnt give much structure to it. Another thing i would like you input in is the observable vs promisses discussion and how you guys at spotify are dealing with asynchronous programming! Keep up the good work!
Hey, I found your channel recently and I'm really digging it. As a primarily C++ dev who's getting into JS, I think your idea of using composition as close to 100% of the time as possible is widely applicable, not just to JS. I am typically in the 'use inheritance when is-a, comp when has-a' camp, but the way you frame the problem makes composition seem logical to use all of the time. I guess you could also multiple inherit if your language supports it, but then you still have a potential issue of bringing code into a class that won't use all of it. I think as far as C++ goes you will still be forced to inherit in certain cases, like using a framework which expects you to inherit from its classes, but I think it's a grand idea to stick to composition in one's own work. 2¢
@funfunfunction Exactly! You can do everything with composition instead of inheritance. but it does not stop there! You can do everything with aggregation instead of composition. and you can do everything with dependency injection instead of aggregation.
07:03 "Inheritance encourages you to build this taxonomy of objects very early on in the project. And you are most likely going to make big design mistakes while doing that. Because humans cannot predict the future."
"I think it's just better to use composition from the start. It's more flexible, it's more powerful, and it's really easy to do."
This is my number one problem in every single project I do. This is coming from someone who always developed in a class oop style, and now changing is so much more difficult because I am so used to what I used to do. However, I agree 100% that it is better in most scenarios, the only scenario that I would use a inheritance over composition is when I am writing a base class and I want to enforce implementation of an abstract behaviour that all objects in future must have.
@@hugodsa89 So for example you make a base composition that the real compositions have to inherit?
like returning the name or type of the composit and some sort of copy function or how to get the 'real' 'raw' data so you can leave that in an array with all other composite data of the same type in sequential memory.
I think something the Video has not mentioned is the fragmentation of OOP data. If you want to update all poop states of all Animals then it makes no sense to jump through multiple pointers to get to the data. This would just give you cash misses and make your program slow. If you keep all position data in one sequential memory your cpu will chew right through it. Loading sequential memory can be 100x faster. Nothing beats an array.
@@hugodsa89 I completely agree. The only time I use inheritance-type pattern is writing interfaces/abstract base classes, but even there it's not inheritance but enforcing implementation as you say.
Amazing quote! 😄
"The problem with inheritance is that encourages you to go predict the future..." Just genius Matt!
Yeah hearing that has been like an epiphany for me. Such a great way of looking at it
Composition gets better with Object Spread (sugar for Object.assign):
return {...barker(state), ...driver(state), ...killer(state)}
is this standardized yet
Red Bear it is standard, but not supported everywhere yet :(
You can use transpilers anyway
Was just about to comment the same thing ! That’s great! Good tip!
Spread operators are not just sugar for Object.assign. Object.assign mutates the given object, thus may trigger object setters while spread operator creates a brand new iterable making it more useful with immutable techniques.
I really love how extremely simple your example are presented! it really makes me roll my eyes when "beginner" guides use long-winded examples where you have to think about a thousand things at the same time and get confused and lost in concepts unrelated to what you're actually trying to learn.
Inheritance is appropriate for single-level abstract classes where you define expectations of abstract methods that MUST be defined in a subclass. You effectively have written a API-contract. In almost all other cases, I favor composition. I love your videos and the style of teaching [often] techno-jargon.
+Thomas Burleson thanks, Thomas! And yeah, that seems like a sensible approach.
Keep up the great work! Your videos are wonderful resources and so appreciated!
Me too very good teacher :D
Why not use an interface instead?
Here from The Odin Project. Great video, very helpful, and explained in a fun way too! Thank you!
Update?
I blame the overuse of inheritance on college focusing too much on OOP and training us to overuse that pattern, and cram inheritance into our projects.
A perfect inheritance hierarchy is a wonderful thing that gives you a sense of structure and a mental model. But it's not feasible in today's agile world cause it's unmaintanable. Most agile projects would benefit from using composition.
Exactly! There are very rare situation where we would like to use inheritance, this idea should nailed in very narrow scenario that can be thinked as undividable unit, though should be inherited. For example of how the barker is barking actually.
What is presented in the video *is* actually *(multiple)* inheritance.
See the discussion here: www.reddit.com/r/programming/comments/5dxq6i/composition_over_inheritance/da8bplv
I think so too. Java was the de facto learning language for computer science in the early 00s and OOP was everything.
@@velocityra that was an interesting read
@@PHILOSOPHYALPHAMALE Still is in many places and the dynamic is the same if they teach C# instead. It kind of feels very anachronistic that they still have such a heavy emphasis on OOP as if it's the end all be all of programming.
07:03 turning point of my perception of programming in general
I always found it hard to implement inheritance in real world applications but still used it thinking that's how I was taught oop and that's how I'm suppose to write programs
thanks a lot for such a great video
For those browsers that don't support Object.assign yet:
if( !Object.assign ) {
Object.assign = function( obj, items ) {
var src = Object( items), target = Object( obj )
Object.getOwnPropertyNames( src ).forEach( function( k ) {
target[ k ] = src[ k ]
})
return target;
}
}
MPJME - I've been a developer for almost 20 years. I've developed in multiple languages - COBOL, ActionScript, Objective C, Java, JavaScript, PHP, etc. I feel like I've always been "behind the curve", because I've had to learn so many languages (frequently starting over). I just discovered your channel last week, and I've been binge watching, because I have learned a LOT from them. You are filling in the pieces that I've been missing from being a "self-taught" developer. I feel like I'm now becoming the top-notch developer that I've always wanted to be. THANK YOU!!!
Program to an interface and not an implementation - this is a good practice
This is a nice explanation. What you consider "composition" is however called "concatenative inheritance". Composition is achieved by passing more specialized components into a more general one. By doing so, you create an object model tree in which objects reference and use other objects rather than making a type tree (taxanomy) in which objects are tightly coupled to their parents (prototypal delegates or parent classes) as opposed to loose coupling in case of composition.
because js and js devs are 'unique' - they invent own term definitions...
Oleg Abrazhaev "composition" is a general computer science term, not js specific
The way he described it in the video seems very similar to composition in Go, so I think the industry is settling on the term.
Exactly! The video misunderstands the term composition, which is actually a delegation of implementation to a delegate object contained within a bigger object (has a).
Host has been replaced by elevator music! I am in love! I will watch every single one of your videos! Next to being funny, you are a great teacher. To the point, so simple, no bs. Thank you!
I have spent about a week reading things that dance around what you have explained so clearly here. Thank you for all you do
Lucky to have found this video. Lesson learned: We can always opt for composition. ex- Car is a vehicle. But Car is also has wheels, engine, seats.
I just have to say: You give the best example of WHY composition should be favored that I've ever seen. Anytime someone asks me, or this topic comes up; I immediately link them to your video. You explain so much better than I ever could. Thanks for that!
hell the first few lines were enough to put it in place. i found you after15 plus videos and yours was the only one who truly explained the difference in how to use them directly while thinking
sanks
The amount of time saved by my brain trying to figure out how to adapt classes for abstraction.
I've just switched back to more of a functional paradigm from OOP, and it's quite refreshing.
Composition for the win.
Good god man.. you just broke my 20 years of Java experience. I'm not even kidding. Big thumbs up for this video
I am a front end developer working in NYC. I really enjoy your explanations and have been watching your videos and coding up all the examples. I really enjoy both your explanations and when you have live coding examples. If you had a paid course I would surely purchase it. Thanks for creating this channel!
It's interesting, I often use both, when I know the inhereted functions will never change. Or they themselves are generics/Utility.
Best of both words!
3.5 minutes in and I have to stop the video to like and comment...you made such a clear, sensible, and persuasive case. Thank you!
One video and I am an ardent fan!!!!! How amazing is this explanation!!! I kept viewing this link over and over again both here as well as medium.com but never actually spent these 8-9 minutes for some reason and kept myself so confused on this topic!!!! For the first time I am so clear as to why most experienced programmers favor composition!
After reading a bunch of articles about this topic, I have to say you really show why composition is better in most if not all cases without over complicating things. The way you explain it deliberately and with simple language really helped me understand just what exactly composition is! I have definitely found myself in past projects saying, Well I already made this class, if I break it up or even remove it entirely then the whole program falls apart. Going forward I'm going to be more wary of this.
I had a dream about trying to flesh out a new program with inheritance. I woke up sweating. That's totally true. Man this video was great. I watched quite a few of your vids now, you crack me up.
This was so good. Clear, concise, complete, and humorous.
Bro makes the design patterns fun! The use cases are well-chosen and the explanation very straightforward. Nice video!
I'm working on transitioning many years of C++ experience into Javascript for a new job and I just wanted to say that your videos have been a great tool to help me figure out the common standards and concepts (as well as helping me prioritize what, exactly, is worth learning in this crazy-ass, over-complicated language lol). There aren't a ton of educational videos that are entertaining and well-produced, but yours manage to be both.
I'd LOVE it if you gave sample "tasks" for us to do to test ourselves. it sounds suspiciously like homework but it's the only way I could ever confirm I understood anything. haha
Oh shit, that is a FANTASTIC idea! I'll try to remember to do it next video.
+Anthony Chung I agree... this requires practical application before I'd know I truly understand it.
yeah it doesn't have to be anything super complex or detailed. maybe just like a brainteaser or something to think about and try till the next week. :) thanks for responding!
+Anthony Chung It's a bizarrely good idea, I think. Especially fronting it as a "brainteaser". It would also be a interesting success metric for the video - i.e. how many was excited by the video enough to try their hand at the brainteaser, and how many understood the video well enough to solve it. I'm not commiting to doing this yet because I like to let idea mull over for a few weeks before doing them, but I really like this concept intuitively.
+mpjme personally, i dont care for it. your videos are enlightening enough where i wouldnt ever feel the need for an exercise. however, i do feel like a github gist for each video would be appropriate
Your videos are awesome for many reasons, but to me, the best thing is that you aways come up with the "But.....". Thanks man, and continue with this great work.
programmers always leave the best comments, I actually read through the comments below and was not disappointed by trolling. I ACTUALLY learned something from other peoples experiences ahahah
For me, a great pivotal point in understanding composition over inheritance was (surprise surprise) a move from BEM to Tailwind. It just proved itself so much more powerful when you can compose your interface from utility classes rather than writing inherited Block Element Modifier rules
Super good point about predicting the taxonomy being at the core of the problem. Well put. Thank you :)
I fist watched this video 2 years ago and now coming back to prepare for an interview
This is so cool! I'm totally on board with composition. Also HUGE thanks for your work! Awesome stuff! The Odin Project represent!
You are a genius good sir.
This is gold!
Funniest, simplest, most bestest articulated video thing on software design I have seen to date.
Thanks! Keep em coming!
You know that scene in The Office when Michael says, ok now explain it to me like I'm a 5 year old.
Well, I feel like you just did that and it worked perfectly. I'm not learning Java but the two concepts flowed into my brain immediately and easily from this tutorial. Simple and effective, and entertaining delivery. Liked!
Wow, that is a great video. I am a huge fan of prototypal inheritance but in less than 9 minutes you just convinced me that composition outperforms the whole concept of inheritance. But then I took some time to think about it, and I found some good parts to inheritance:
1) built-in objects in JavaScript have a huge list of properties and methods, that are spread over a prototype hierarchy like HTMLDocument > Node > Object. This hierarchy can trap you, but also help to separate layers of functionalities. So you can easily iterate on an object's properties without having to deal with all the methods inherited from Object.prototype like toString, constructor etc...
2) with composition, everything is _flat_, which can be a good thing at first look but can lead to overly complex objects (document.body has a total of 252 properties for example)
3) it is easy to extend a method behaviour with inheritance: you just override the function and call super() or equivalent. composing makes things quite harder : if I need to change the bark method of my RobotDog to bark(){ barker.bark("with a robot voice") }, I cannot compose it with barker. I would have to manually assign a bark method which instantiates a barker, call the original bark method in the context of the the RobotDog object, then add the extended behaviour, and things just became much more complicated.
What are you thoughts on this ? Anyway, great video, you rocks !
All three can be done with composition just fine.
+mpjme Or rather, not iterating over all properties without hitting the parent properties, but the only reason that you need to do that in the first place is because objects contain a bunch of crap that you're not interested in.
2. Composed objects don't necessarily have to be flat (even though they are in my simple example) you can hide inner objects inside composed objects and only expose things that you need on the outer API surface area. Document body is that big BECAUSE it uses inheritance - that is the problem with inheritance, you get an enormous amount of functionality that you don't need.
3. Again, just hide the inner implementation inside your composed object.
+mpjme But if you hide inner objects in composed objects closures, there are no longer exposed to user ? I think the assumption "objects contain a bunch of crap" is a bit simplistic
You hide the things you want hidden. If you need something to not be hidden you just expose it. You could also expose the inner object as a property. That way, you'd get even more granularity than an inheritance model.
I've just stumbled upon this video searching composition vs. inheritance for C# to take a second point of view as it was still unclear after watching a lesson from a course on Udemy. Your funny and practical approach was so clear and enlightening that instantly earned both my like and subscription.
Thanks for taking your time to share it with lost travelers (:
I just discovered you today, you makes things easier. And you code is so elegant, you make art with your code.
came from the odin project. can't remember if it was linked directly there or if this was linked in an article they had me read. I love your energy and you explained this in a way where somebody who's struggling came away knowing more than I did. thanks so much.
Dude I just answered a question about composition on quora and referenced this video and the picture it chose to use of you is freaking hilarious.
Odin Gang? Where are you ????
✋
Here and struggling
Here and struggling with javascript haha
@@Game_Experience.we all certainly are 😂
But hey you made it 🎉
@Mike-kl5yc I actually restarted the Javascript section 😂 I got stuck on the Javascript path
Love this "Real World" explanation training style. Great job!
A young Christopher Waltz explaining engineering concepts quite well. This kid has a future :)
Thank you so much for these videos they're by far the most concise yet clear and straight to the point.
With a statically typed language, inheritance is great for extension. I almost never use it for defining domain concepts, more for elegantly tapping into the language - a workaround :D
Great video! I've just read 100 pages on inheritance in "Secret of the JavaScript Ninja" by John Resig and I had so many doubts about going this route and now I have an alternative to explore. Thank you so much!
Bob Ziroll's React video brought me here!
LOL same
Man this is such a fantastic vid. Thanks for the wisdom. Inheritance seems like such a natural way to think about things. (I was introduced to classes via Django) but I have faced the exact problem you defined above. Must rethink object construction using composition.
I love how you described the problem of composition vs inheritance.
From my experience, i see inheritance as powerful tool how the small tool-set, or a feature, that has been developed. Small enough that a structure can be reorganized, and inheritance rethink-ed again. Usually like up 2 or 3 levels, but possibly no limitation if this hole deepness is predictable from code design.
So to be more specific. Pure composition says that there are used, and those who use. Only 2.. Master and the slave. If we think about inheritance we have a common behavior for all set of parent->child->...->child and those can be used as object of 1st level only.
From this given example are only for showing the benefit of composition. Benefit from inheritors is all about how Barker barks, or meower "meows", where the inheritance will be a better choice. Thank you!
Thanks for your videos, they are amazing.
After watching the video I didn´t know how to change the state, if it needs to be changed. I put my fingers in movement and I found two approaches:
1st, use a setter:
const barker = (state) =>({
bark: () => console.log(state.sound)
})
const setter = (state) =>({
set: (key,prop) => {
state[key] = prop
}
})
const dog = (name) => {
let state = {
name,
sound: "woof"
}
return Object.assign(
{},
barker(state),
setter(state)
)
}
let rufus = dog("rufus")
rufus.set("sound", "I'm rufus")
rufus.bark() // I'm rufus
2nd, use state to create the object:
const dog = (name) => {
let state = {
name,
sound: "woof"
}
return Object.assign(
state,
barker(state)
)
}
let rufus = dog("rufus")
rufus.sound = "I'm rufus"
rufus.bark() //I'm rufus
Which approach you think is better?
Thanks in advance.
BEAUTIFUL. thanks so much for the easier description. I have been hearing about it but, let's be honest, a lot of the resources befuddle their explanation to a bunch of terms and I personally learn better with examples. So thank you. I actually started learning OOP in college, so it is pretty hard wired into my mind until the job I'm in which they dont' want OOP... I never understood why until I started reading about this recently.
Absolutely love your show, I think your show is so beneficial (and fun and interesting and awesome etc...) not just because of your skills as a programmer, but also your ability to *keep things simple* in your explanations! Often people explaining things like to over complicate things to "sound smarter".... not fun at all.
Please keep it up!!!!
I started understand behavioral composition is more powerful than inheritance via concept...thank you for your easy-to-understand video! Appreciated sharing your opinion, learn something new about JS! :)
As a (French ^^) PHP developer, your JavaScript approach is so interesting and so clear !
Thanks a lot for sharing your skills :p
And stay curious ;)
The way I learned the is/has distinction isn't as composition vs. inheritance (where it really makes no sense, as you said), but rather as how you decide whether something should be a subclass (which can be done via composition or inheritance) or a member object.
I see inheritance as an attempt to port over a concept from languages where it makes sense (more strongly typed languages make composition much more difficult if not impossible) to a language that doesn't really need it.
A super tutorial I found about Composition and Inheritance in JavaScript. Thanks mpjme!
LIGHTBULB!
You just made my day. You just leveled up my programming skills in 8 minutes. Thank you!
im going to use this as the bases for my future programming, after going down a rabbit hole of inheritance, fake classes, i keep hearing about all the problems associated with "this" and how the paths can be convoluted, even for me to understand watching the examples it becomes almost impossible to follow the path
I like the focus on what objects *do* versus what they *are.* This is a good example of a shift from one pattern to another. However, it relies on an unknown object (called "state") for the factory function pattern, and might make it more difficult to understand how the composition example maps onto the inheritance-based design. So, firstly, you'll still need an interface or a type for the "state" object passed into the factory functions -- in this case, it must have "position" and "speed" attributes for the drive method of "driver" to work. Secondly, if "barker" relied on any additional attributes, you would need to ensure the state object implemented those. This leaves you with the need for additional interfaces (which themseleves may or may not use inheritance for other reasons).
I agree with Antony Chung. Some sample tasks would be greatly appreciated. I am new to coding and find it difficult to find tasks that might further my understanding of the more complex concepts. Thanks!
"Its like you ask for a banana and you get the banana but a gorilla is holding it" 😂😂 I love this. Thank you so much🙌🏾
And the entire jungle with it!
great explanation thank you! will definitely be running with composition over inheritance! long live the prototype!
This is so funny, I am using composition strategy it in solidity and it works perfectly. The mechanism there are modifiers, they also grant permissions as well.
I've been taught in college the inheritance concept as one of the core concepts for OOP. Inheritance is widely used, now and then one will encounter it. The composition concept is much more flexible and maintainable, though. I'd rather implement composition, but I think it is important to know the inheritance syntax.
I especially like this video! Very exciting to learn about composition :)
Really thankful for your videos, they are informative without being boring, and tells me just enough about a topic to get me excited about diving deeper into it.
Would be nice to hear about some more ES6 goodies that I should be using!
+My Högblom Thanks, My! Might be some ES6 stuff coming in the pipe, we'll see!
You speak to me from the soul, as always. Great video.
Composition outperforms prototypal Inheritance not only in simpler structure but also in better readability due to the fact, that you don't have to use that f.....g "this" anymore.
Sadly I can't come to this years JS-Conf because some serious childbirth is going one here :). I'd love to have a chat with you there.
Have Fun in Berlin!
Fantastic. This is easily the best explanation of classical vs prototypal inheritance I've run across. Great vid! New subscriber right here
Composition of capabilities is a very good design pattern.
The new features makes it even more advantageous.
// Shorthand property names (ES6)
a=1;
b={a}; // { a: 1 }
As functional programming also employs composition it seems fitting to think like a composer rather than a geneticist.
I think I get where composition can keep things clean and strategic, but traits/mixins also seem like a way to effectively grant classes functionality without risking inheriting more than you need.
Even though I agree that it is easier to think of what an object "is doing" rather than what "it is", it is very easily doable with interfaces. In your example, I would have many interfaces (bark, poop, drive) and each class would implement the interfaces t needs.
+bobdudan Having classes that implement multiple interfaces actually is "composition" as described in the video. It's only when you start to share implementation details between the classes that you are in trouble. In simpler terms for Java programmers: "implements" is good and "extends" is bad.
Even though this video is 5 years old, it's still is greatly applicable. 👍🏽
Very well explained, and it's true : use composition
I'm new to the concept of factory functions (well, JS in general) but I understand Object.prototype.someMethod as a way of creating methods or properties that an object can inherit. One of the major benefits as I understand it is that if you have your object inherit methods rather than instantiating objects with them it's more memory efficient. Using this concept of factories, and composition, are you getting the same benefits? If I create 10 murderRobotThingies, am I creating 10 objects each with their own method, or are they kind of inheriting the method, almost like I used the Obj.prototype pattern?
Same Question. notice us mpj senpai
3 years and still no answer
I've always felt that composition should be used when you want to share behaviour (driving, pooping, etc) and inheritance should be used when you want to differentiate/separate (Maybe has a Some vs None or the difference between a GuestUser vs AdminUser).
It's also important to keep in mind that you can use both at the same time, they're not mutually exclusive. For instance, a GuestUser and an AdminUser might have common behaviours through composition, but differentiate in property values or have overridden functions.
Such a brilliant example! Thanks a lot
Almost 3 years later... And you just made a major part of JS so damn simple.
first time seeing your video from a friend's referral, haha, you crack me up and it's interesting to see daily life example that you used to better illustrate the concept. thank you and I subscribed.
+Jim Kang Hey jim, that's great to hear. Welcome to the channel and say thanks from me to your friend!
Brilliant video, loved the Robot Murder Dog made me laugh. It's very thought provoking and I love the idea of composition because you only get the functionality that you need over all the functionality you might need or just because some other children use that functionality I'm going to have to learn more about it.
this video is actually making me laugh my ass off dude I love it, super helpful too as I'm trying to learn why inheritance is generally considered outdated now!
At First.. I felt reluctant to watch the video with such Handsome Poster Image ( : Scarcastic :D )
But then...
I am spellbound by the way you have conveyed such a concept with such innovative, indulging and entertaining way..
Kudos. Yo!! your video rocks. I ill subscribe and follow your Videos :)
With love from India !
I love the idea of mix-and-match types, it's like the best of both worlds between Classes and Interfaces. However, wouldn't it be difficult in a larger scale app to keep track of which properties are in which classes? Say I wanted to add "barker" into the Object.assign - wouldn't I have to check ALL my other factories to make sure I'm not overwriting anything?
Those examples are absolutely top notch
As soon as I started it he recomended the previous episode and as soon as I started the previous one he recomended the previous previous one and then previous previous previos one. I almost got into an infinte loop, but I terminated my inquiry ultinately.
straight to the point and crystal clear
hey, love your show.
can you please make an episode about modules and separation to different files.
thank!
I really appreciate your videos MPJ. I'm not working as a front end dev yet but I think these vids will get me there sooner rather than later.
I also really enjoyed starting this video at 1:52 at 50% speed and seeing how drunk you sound :-).
awesome video! i feel like these 8 minutes made me a much better developer
Outstanding tutorial, thanks a lot.
I really liked the way you presented this topic.
Just found about your channel. Clear and fun explanations! Keep up the good work!
This explanation is clear AND hilarious. Thank you.
I really loved the video and i end up here after follow the stamp project e all the discussion over composition after the react release.
I would like some tips, or even a sequence video for this one, on how to organize projects where the developers use composition. In my OO or MVC projects this is really straightforward but now with composition i am ending up with a huge helpers and functions directory witch doesnt give much structure to it.
Another thing i would like you input in is the observable vs promisses discussion and how you guys at spotify are dealing with asynchronous programming!
Keep up the good work!
Awesome explanation also very funny , why I didn't seen this channel♥️👍
I couldn't wait to subscribe to your channel after watching this video. Love.
Hey, I found your channel recently and I'm really digging it. As a primarily C++ dev who's getting into JS, I think your idea of using composition as close to 100% of the time as possible is widely applicable, not just to JS. I am typically in the 'use inheritance when is-a, comp when has-a' camp, but the way you frame the problem makes composition seem logical to use all of the time. I guess you could also multiple inherit if your language supports it, but then you still have a potential issue of bringing code into a class that won't use all of it. I think as far as C++ goes you will still be forced to inherit in certain cases, like using a framework which expects you to inherit from its classes, but I think it's a grand idea to stick to composition in one's own work. 2¢
We need one of you ... for each programming language.
I love this. Inheritance is a pain in the ass.
+Nerdcoresteve1 maybe you're just thinking about it in the wrong way?
@funfunfunction Exactly! You can do everything with composition instead of inheritance. but it does not stop there! You can do everything with aggregation instead of composition.
and you can do everything with dependency injection instead of aggregation.
First time here and dude you're awesome. The way you've explained all of this is fun, engaging and entertaining. Liked & Subscribed.