"The problem with inheritance is that encourages you to go predict the future..." Just genius Matt!

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."

Composition gets better with Object Spread (sugar for Object.assign): return {...barker(state), ...driver(state), ...killer(state)}

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 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.

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

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.

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; } }

Here from The Odin Project. Great video, very helpful, and explained in a fun way too! Thank you!

By Jove! This is the most eloquent explanation as to why composition is a less complicated route than inheritance. Thanks for sharing!

I have spent about a week reading things that dance around what you have explained so clearly here. Thank you for all you do

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 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!

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 so cool! I'm totally on board with composition. Also HUGE thanks for your work! Awesome stuff! The Odin Project represent!

Bro makes the design patterns fun! The use cases are well-chosen and the explanation very straightforward. Nice video!

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.

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

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

This was so good. Clear, concise, complete, and humorous.

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!

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!

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

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!

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 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.

great explanation thank you! will definitely be running with composition over inheritance! long live the prototype!

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!

Love this "Real World" explanation training style. Great job!

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!

Thank you so much for these videos they're by far the most concise yet clear and straight to the point.

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.

I just discovered you today, you makes things easier. And you code is so elegant, you make art with your code.

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

Very well explained, and it's true : use composition

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.

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 (:

Such a brilliant example! Thanks a lot

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.

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 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).

Those examples are absolutely top notch

Good god man.. you just broke my 20 years of Java experience. I'm not even kidding. Big thumbs up for this video

Bob Ziroll's React video brought me here!

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.

LIGHTBULB! You just made my day. You just leveled up my programming skills in 8 minutes. Thank you!

We need one of you ... for each programming language.

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!!!!

Came here from odin project. Great 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.

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.

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 !

Thank you! This was very useful and insightful!

A super tutorial I found about Composition and Inheritance in JavaScript. Thanks mpjme!

A young Christopher Waltz explaining engineering concepts quite well. This kid has a future :)

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!

straight to the point and crystal clear

I couldn't wait to subscribe to your channel after watching this video. Love.

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

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.

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'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?

This is such a great use of analogies.

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!

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.

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.

"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🙌🏾

Awesome explanation also very funny , why I didn't seen this channel♥️👍

Fantastic. This is easily the best explanation of classical vs prototypal inheritance I've run across. Great vid! New subscriber right here

Just found about your channel. Clear and fun explanations! Keep up the good work!

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!

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!

hey, love your show. can you please make an episode about modules and separation to different files. thank!

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.

Superb comparison. Hats off

Outstanding tutorial, thanks a lot. I really liked the way you presented this topic.

Even though this video is 5 years old, it's still is greatly applicable. 👍🏽

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

Inheritance is like using nested folders. Composition is like using tags.

This paired with inversion of control s a sick programming style.

Odin Gang? Where are you ????

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 ;)

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!

Love this video..clared the concept with humour...

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.

The interesting thing is that composition is thought of as 'has a' but in your examples you name the abstract objects as 'barker', 'driver', 'killer', etc. which sounds more like 'is a' to the composite object. So although MurderRobotDog is a composition of objects, it 'is a' 'barker', 'driver', 'killer' - rather than 'has a' 'barker', 'driver', 'killer'. So although its composition, it sounds and almost feels like inheritance.

great explaination, thanks

This explanation is clear AND hilarious. Thank you.

Thanks for your awesome videos mpjme!

awesome video! i feel like these 8 minutes made me a much better developer

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.

Almost 3 years later... And you just made a major part of JS so damn simple.

This is an excellent video. Well spoken and explained.

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?

Absolutely great video! So good examples, thank you very much!

Yes, many times, composition is favoured over inheritance, but there are some cases where inheritence must be favoured over composition. Mainly when there are a lot of classes that share similar code. If we use composition in this case, then we will have to write a lot of duplicate code.

First time here and dude you're awesome. The way you've explained all of this is fun, engaging and entertaining. Liked & Subscribed.