Composition Vs Inheritance - Why You Should Stop Using Inheritance

🚨 IMPORTANT:
1 Year Free Hosting: www.atlantic.net/webdevsimpli...
Use code KYLE for an additional $50
Object oriented programming has been around for a very long time and is one of the most popular programming paradigms, especially in academic curriculum. Unfortunately, pure object oriented programming is not the best solution to many problems. This is why in certain industries, like game development, the idea of composition has risen in popularity to overtake inheritance from object oriented programming. In this video I will explain the differences between inheritance and composition through one example program. I will also go in depth about the problems with using inheritance that composition solves. This was an eye opening concept for me when I first learned about it, and I know use composition all the time in my code.
📚 Materials/References:
Destructoring/Spread Operator Tutorial: • Why Is Array/Object De...
🧠 Concepts Covered:
- What inheritance is
- What composition is
- The differences between inheritance and composition
- Why composition is better than inheritance
- How to write composition based code
🌎 Find Me Here:
My Blog: blog.webdevsimplified.com
My Courses: courses.webdevsimplified.com
Patreon: / webdevsimplified
Twitter: / devsimplified
Discord: / discord
GitHub: github.com/WebDevSimplified
CodePen: codepen.io/WebDevSimplified
#CompositionVsInheritance #WDS #CleanCode

[@ErrorDebug]

its all good but i dont think shark can walk

[@byambaaerdene2127]

Watch sharknado and be entertai, i mean educated. There you will see sharks not only ... but can fly too.

[@jasonleelawlight]

your comment is the best haha

[@skaruts]

That's actually an example of another problem with inheritance that he neglected to mention: you end up with classes with needless functionality. And this is a more prevalent problem than it may seem.

[@bluesky_10]

Lol. this shark is monster bro not the usual shark (beautiful one)

[@Valyssi]

Although many people would argue memory isn't much of an issue in most code except a few specific use cases, I think it should still be mentioned in a video like this. When you're creating functions in this way, without prototypal inheritance, you're creating separate functions for each object instance. With prototypes you'd only have to create them once. This can impact your memory usage, although this is generally only an issue for very large functions or if you're creating thousands of instances per frame, or if you continuously add instances that aren't removed from memory. Those are relatively rare use cases. Most often you'll be creating singletons or under 100 instances of an object accessible in any given frame, in which case the maintainability and expandability of composition should be preferred. However, if you ever did have to switch to prototypal inheritance for performance, you'd have to change your entire implementation.

[@arcadeduo7101]

It is possible to manually create an inheritance prototype by using a constructor function and manually setting the methods as prototype methods, right?

[@vukkulvar9769]

@@arcadeduo7101 You can. You create every method as a function, and then you attach it to the prototype of the object / class. // Example const myPrototype = { foo: foo }; const myOtherPrototype = { foo: foo }; Object.setPrototypeOf(myObject, myPrototype); Object.setPrototypeOf(myOtherObject, myOtherPrototype); // And if you want to combine prototypes freely : const prototypeFoo = { foo: foo }; const prototypeBar = { bar: bar }; Object.setPrototypeOf(myObject, { ...prototypeFoo, ...prototypeBar }); // Warning: This method do not go well with the use of the instanceof operator.

[@lilyscarlet2584]

if only the interpreter knew about function inlining...and if only there wasnt a hierarchy of object instances that were created every time you wanna do a simple thing...the real problem is that the web is not very well designed for how we use it today and javascript isnt a good language to begin with. there is nothing maintainable or good about forcing object instantiation lets just be honest and not defend oop. javascript was an unhappy accident we are coping with and frontend web has way too many layers and language transpilation and it would be better if we could somehow standardized web assembly and replace the DOM with something more sane for a dynamic web app. and we also should change our mindset about how we write code in general when it comes to web having all these messy callbacks is not a very good system. not to mention alot of companies are like 85% bloated and there are way too many people which increases the communication barrier and thats the only real justification for writing code like we do which ends up overly abstracted to the point where its hard to understand whats going on or how much memory things are using and debugging etc. and to be frank almost nobody in web is doing actual programming. and unfortunately all of the bad flaws of the web are bleeding into other areas as well and software is degrading as a result. this is probably a better alternative but again when you are dealing with constructors and objects its hard to write code that doesnt bloat out in an intuitive way and it even encourages code that is less efficient which is another fundamental flaw in web and in javascript. i guess most people are just used to this and think its normal to code this way but to me it looks like a mountain with a toothpick as its only foundation and one wrong move and the whole thing crashes down and destroys entire towns. thats how i think of web infrastructure or like a jenga game where you pull the wrong piece and the whole thing just implodes on itself. or even worse javascript allows buggy code to work and alot of things never get fixed as a result. i guess thats why you have transpiled languages like typescript but that just makes javascript an assembly target and its not a very good one at that. it just seems like everything is a cope for the fact that web infrastructure is an arbitrary thing that came to be from history and wasnt designed to work the way we use it today so we add a bunch of bandaid hot fixes and now you have all this needless complexity as a result. im curious what people think of this do you agree do you think we could do better or do you have the mindset of well it works so dont fix what isnt broken. its more of a philosophical question than anything. im on the side of i wish we could do better and i wish more people were like minded instead of going forward with how it is. but im open to hear more insight.

[@lilyscarlet2584]

@Dragon my point is that most of that complexity shouldnt be there you shouldnt need libraries to get around how bad js really is. the issue is that the web isnt designed to be used like it is it wasnt designed well to begin with. new technologies keep popping up all the time all of which are low quality. nodejs included. the excuse that apps are getting bigger doesnt justify its problems. most apps are much bigger than they should be requiring a much bigger stack than what should be necessary to run. wasm may help but time will tell.

[@zaza-ik5ws]

@@lilyscarlet2584 Which is the best programming language in your opinion?

[@neverchesterfield]

Incredible feeling when I finally understood why you'd need composition: "what if you wanted a monster that can swim and fly" and, as someones who *hates* copy-pasting code it actually struck me. Thanks !!

[@paxer2k]

Design patterns? Interfaces? Abstract classes/methods? C++ can even use multiple inheritance. Furthermore, within JS, you can just apply the principles of interfaces and it will tackle the issue just fine.

[@neverchesterfield]

@@paxer2k Did you mean to answer my comment?

[@ipodtouch470]

@@paxer2k multiple inheritance can be messy though especially if you run into the diamond problem.

[@GameFuMaster]

@@paxer2k Except inheritance is flawed because it requires foreknowlege. When you look at it, swimming and flying are basically the same thing, except they're through different mediums (liquid vs gas). They both move in X, Y, Z directions. When you use inheritance, you're stuck with your initial presumptions. With composition, the input matters much less, and you just need to worry about your outputs being correct.

[@harleyspeedthrust4013]

@@paxer2k interfaces do solve the problem - at the end of the day you shouldn't be using JS if you're building serious software. the problem with interfaces and classes is that they are poor models of real data structures. code changes, and inheritance hierarchies are a bitch to change. it's also very easy to go crazy and overuse inheritance, especially in a language like java where everything has to be in a class even if it doesn't make sense. as i mentioned before, the biggest problem with inheritance is that it rarely models data structures and relationships well, so you end up fitting the problem to the code when you should be fitting the code to the problem. "use the right tool for the job;" inheritance is almost always the wrong tool.

[@ericcartman4799]

JavaScripts (functional): missing something, lets add Classes JavaScript(classes): you know what, Classes sucks back to functional

[@christianmartinez2179]

You know what? JavaScript sucks let's go back to bytecode (WAS)

[@yackawaytube]

Classes don't suck if you use them right. Every tool solves a specific class of problems - pardon the pun.

[@TroenderTass]

@@yackawaytube Compared to not having classes, yeah classes suck. Most of the time, you just don't need that fucking class. I hardly any class solution that couldn't be solved just as efficient with a functional module for instance. There is just no need for them, what so ever.

[@thebe5twon-minecraftbikera979]

@@TroenderTass Well, that would likely be because classes are just a nice way of writing a constructor function and prototype functions. Prototype functions are important for memory management because you aren’t making new function objects in memory every time you make a new object. The issue I have with this video is he isn’t even making the same thing as a class that can swim and fly because each time he wants to let the monster swim or fly it’s a new function in the object, not a function in the prototype object.

[@TroenderTass]

@@thebe5twon-minecraftbikera979 You are disgussing something very different than me. A class is also a wide and general concept outside javascript constructor functions, and in general being able to create functions as an independant snippet of code outside the constraints of an object is alot more powerful and efficient than having to traverse and be constrained by a class hiarchy like languages like java. If you by any means find it easier to use those class based constructs over functional supporting languages, than you really are stuck in a convoluted way of thinking, and not willing to expant your mind into more productive code. A js class isn't really a class, and is not a really what i had in mind when i said that you in general don't need a fucking class. Classes are really overused stupids concepts, outside those few cases where they can be handy, wich are rare.

[@romarpatindol9840]

For how many years of just copy-pasting codes now I understand, I am amazed at the principles and the art behind the logic and you've nailed it by explaining it well, very straight to the point. Thank you man!

[@knightmarerip711]

This just blew my mind away! For a few months now, I have been looking for a way to write better classes. Rather than having all my functions defined in a class, which makes it bigger that it should be, I wanted to define classes outside and just reference them when I construct my class. This is really awesome! Thanx for sharing!!!

[@pagatelabirra]

With new object prototype methods you can return Object.assign(monster, swimmer(monster))

[@rajeevsinxh]

when he said "the ability to create a new type of monster is really powerful" I cracked lol

[@Nerffye]

I just discovered your channel and I must say you have a great way of explaining things. Thank you for excellent work ♥

[@mrfreddie04p]

I have a small problem with this solution. swimmer() and flyer() functions appear to get access to the "name" value via closure. So, if I update the name property after creation the object, it would not be reflected in swim() and fly() functions. They would still output the original name.

[@porobertdev]

You need to use the `this` keyword which tells what context to use. The context of a method is the object owning that method. But the type of methods used here are arrow functions. An arrow function doesn't have a context on its own, but it "inherits" or uses the context of the outer function. Since the outer function is a regular function, the context (`this`) is the global object: `window`. Thus, we need to switch from arrow function to a regular function (method). function swimmer(name) { return { name, // "shorthand" for name: name swim() { console.log(`${this.name}: sweam`); console.log(this); // object created } } } let monster = swimmer('Robert'); // monster = { name: 'Robert', swim: ... } monster.swim(); // "Robert: sweam" // this = monster object A great article on the `this` keyword is this one: dmitripavlutin.com/gentle-explanation-of-this-in-javascript/

[@emibademi1]

What about memory efficiency for example: What if we have tons of monsters? All the monster methods will be copied in every monster that we created without using prototypal inheritance.

[@SurenEnfiajyan]

Good point. But from the other hand with prototypical inheritance the property access time increases.

[@jonteguy]

@@SurenEnfiajyan Polymorphism is inheritence by nature. This guy is attempting to make it sound like it's composition, what a tool he is, he should not be educating people to the extent he is attempting to in this video. Is inheritence being misused? For sure. But people misuse it because it is a simple way of coming up with a solution, you can use inheritence very effecitely if you just understand what real good design is. I use both composition and inheritence, as you should because not all tools are made for the same problems.

[@arifwahyudiansyah2809]

Because inheritance is so important in object-oriented programming, it is often highly emphasized, and the new programmer can get the idea that inheritance should be used everywhere. This can result in awkward and overly complicated designs. Instead, you should first look to composition when creating new classes, since it is simpler and more flexible. If you take this approach, your designs will be cleaner. Once you’ve had some experience, it will be reasonably obvious when you need inheritance. (Bruce Eckel)

[@harleyspeedthrust4013]

agreed. inheritance is almost always the wrong tool for the job, but when it fits, it fits well. that's rare though and new programmers should be taught to fit the code to the problem rather than fit the problem to the code. it's a sad mistake that java is taught in so many schools around the US as a first programming language, but then again this is the same country with a high school physics curriculum that has been stripped of calculus. it's ironic that isaac newton invented calculus to describe physics and some big wigs in suits decided he was wrong

[@jonteguy]

^This, it is so annoying to see people talk bad about inheritence when they simply do not know how to use the tool effectively. Also he is talking about polymorphism but he doesn't mention that, polymorphism is inheritence. The guy who made it is a tool.

[@kevinrobertandrews]

I love that you can talk about high level concepts while still writing real code. Amazing, and subbed!

[@WebDevSimplified]

Thank you!

[@xKhfan213x]

I'm a little late seeing this but the comparison of these ideas along with the examples you gave is a pretty good example of the differences between object oriented programming and functional programming. With inheritance, you are following the oop paradigms. Everything is an object extending the capabilities of other objects. Composition on the other hand has you break your objects into separate functions. You can then just take which functionality you want to inherit by adding the function to the object your creating. Think of this like a Lego set. The functions you create are your Lego pieces. To create an object you just piece together your Lego pieces. Which is better is a verry debatable topic, both having their pros and cons. Just remember what one can do, the other can as well and it's typically best to follow either oop or functional programing practices and not mix them in the same project. It can be confusing for other developers, especially if they aren't familiar with functional programming

[@stephenhowe4107]

Yes but there are situations where inheritance is a good choice and others where it is a poor choice. This clip gives food for thought and at the same time reveals language limitations to your ability to model the situation.

[@jonteguy]

This is not true, polymorphism itself is inheritence and that is what he is talking about. He has no freakin' idea what he's talking about in this video. Look up polymorphism if you are not sure what I'm talking about. It's a joke. Also oop can be just as fast and neat as functional programming, people are simply misusing it tremendously because they don't know better, it is simply a simple way of doing things. Also, again: polymorphism is inheritence but it is also functional programming. This guy is a tool, he should not be educating people to the extent he is attempting to.

[@nerdiloo9863]

Good stuff. As always there's more than one approach. This one I'm sure to use.

[@user-cy3kn7zx1l]

Is there a reason for wrapping those methods in an object to then be returned from a function rather than referring to those functions in the creator return object itself?

[@piyushdanej3930]

GOod ques. I guess in this case , it saves implementing the fly and swim functionality again and again and commonly implementing them just once. In real world you'd make an interface Flyable and implement that interface everytime and Use the principle of composition while creating objects. That way you'd provide specific implementation to your concrete classes . Everytime.

[@codingchannels4103]

please provide final code file in the description for us to easily look up the code

[@mynoghra1849]

I don't even do javaScript and I understood you perfectly. Beautiful explanation!

[@cburys]

Solid explanation and tutorial. I think this is very useful implementation of a factory design pattern. I'd use interfaces as return types to keep it type safe in ts.

[@neozoid7009]

Awesome tutorial . thanks for making this type of contents 👍♥️

[@pinkleprechaun52]

is this the same as mixin? also, other than the flexibility, does it have any impact on speed? does using inheritance vs. using composition has an advantage in speed or are they just the same speed?

[@CaamSerenity]

Wait until he learns about TypeScript and how to use interfaces properly. Alternatively, to achieve the exact same result but way more readable, Mixins.

[@thedankest1974]

Well said.

[@yackawaytube]

I find AOP using decorators to be superior approach to address cross cutting concerns than mixins

[@CaamSerenity]

@@yackawaytube Depends on what you want to do. The problem with decorators is that they are not allowed to add properties to a class in a typesafe way. Mixins can do that. I personally prefer decorators as well, but sometimes they are not the right tool for the job. Though, often they are. In this example they'd not be as great.

[@rgablejr]

Great explanation and examples!

[@jacobpolicano7289]

Does this have a negative impact on memory and should we consider that when deciding between composition and inheritance? I notice we are recreating these functions every time we create our new Monster, but with the class-based approach we're actually referencing a single object that houses our related functionality.

[@coder_one]

Great question! Without using prototypes, whenewer we create new object we repeated all these methods, without using the prototype chaining. This probably causes a lot of memory loss

[@ikemkrueger]

@@coder_one Memory is cheap today.

[@CottidaeSEA]

@@ikemkrueger Google Chrome..? :)

[@redcrafterlppa303]

You described a perfect case for interfaces. An interface describes a functionality multiple classes might have. Like Flying or Swimming. But you solved it with an unreadable mess of lose functions and higher order function like objects. This is not only bad code in every way but also extremely wasteful. If everyone would write code like this every website would take minutes to load and code maintainability wouldn't even be considered and everyone would need to rewrite everything constantly since nobody understands a mess like this. This is a proper way to solve this: interface Walk { function walk(); } interface Attack { function attack(); } interface Fly { function fly(); } interface Swim { function swim(); } class Monster implements Attack, Walk { function attack() { ... } function walk() { ... } } class FlyingMonster extends Monster implements Fly { function fly() { ... } } class FlyingSwimmingMonster extends Monster implements Fly, Swim { function fly() { ... } function swim() { ... } } This is a clean solution solving the problem of inflexibility of classes. Also the example is flawed in its core. The implementation of 2 flying monster will in general be different anyway so there is no code duplicated. And if there is shared code it is an implementation detail and should be extracted into a hidden helper function. Inheritance and composition describe public apis and are designed to describe relationships between objects. They aren't meant to simply deduplicate code. Code deduplication is a side effect of a clean code structure.

[@smaranh]

Brilliantly explained as always.

[@pete2153]

This guy reminds me of Code Drip. No bs, just straight to the point. I don't really tend to subscribe to too many of these types of channels but this guy always gives good advice.

[@abcabc00000]

But in this case if you think it from the prospective of closure, for the methods inside the returned object from function flyingSwimmingMonsterCreator is holding multiple memory referance for the value of "name". Will it not waste tons of memory?

[@Bonzvy]

Very well explained! Thank you!

[@ohiwantyoutobelieve]

This is gold, excellent explanation, thank you very much

[@anonlegion9096]

How do you emulate static properties/methods of classes using composition?

[@mukulodd3122]

Thank you, Your videos are really very helpful !

[@muzafferckay2609]

I was confused why function return object in Javascript. This is because function is called is to create a new object each time like create instance in oop. Am i right?

[@1flybyguy]

The wardrobe changes are messing with my mind. You still have a soothing voice, so I'm good.

[@soniablanche5672]

Plot twist: Inheritance in javascript is actually composition under the hood.

[@olezhonnv3215]

@MUSICAL INFLUENCE You can do class two extends three class one extends two But there is no multiple inheritance in js. You cant write class one extends two, three

[@bayrock1337]

Even more reason not to use it.

[@sunnz]

How does Atlantic compare to DigitalOcean, Linode, and AWS?

[@rebelmachine88]

I'm a web dev learning to make games, so this example was super relevant for me! Thanks for the video!

[@waterp2202]

Question?, how you use extends in composition?

[@MrJaminbrad]

How do you feel about mixins vs this composition pattern? They both solve the inheritance issue, but the only difference I've come across in my limited experience is mixins still rely on 'new' and 'this'.

[@WebDevSimplified]

Mixins are a version of composition so I think they have the same benefits and disadvantages as composition like this video shows.

[@RayParker]

The problem with your premise is that all of the actions should have been declared and the Monster level and then the specific monster classes respond in the positive to their specific actions. For example, when you ask a monster to swim he might just sink or something, but a Shark swims like crazy.

[@razbuchnik6007]

You may define types of swimming. bird.swim and fish.swim are two different methods. You may apply each of them respectively. Like so: const bird = { swim() { } } // may only just sink, must go up after 10 seconds, cannot go too deep const fish = { swim() {} } // different entirely from bird swim - can do just whatever he wants in the water function sharkMaker() { return { swim: fish.swim } } and function birdMaker () { return { swim: bird.swim } } Which are two different things

[@theBigBugGuy]

Can we implement this using function borrowing, call, apply or bind?

[@anthonychurch1567]

Great video to show some sort of functional composition but it is slightly confusing given composition is an OOP concept. Came here after learning OOP and for the purpose of composition with JS classes. Just to note that would help avoid confusion when doing OOP to suddenly be using functions. Really cool that you can achieve the same thing without classes though if you want to use functional code instead!

[@Ag-kl9jx]

Really super! Thanks.

[@ajsimwork8887]

this is great. thank you!

[@swathikumar3074]

thank you so much for awesome explanation

[@damienminter1999]

I am kind of struggling to understand why all the composition examples are using pre ES6 function declaration syntax rather than arrows. I have noticed this with quite a lot of different videos from multiple content producers across a number of subjects (ES6 modules for example) - Why shouldn't we use arrow functions in these cases?

[@thescottyjam8906]

Arrow functions aren't meant to replace function declarations. They're both useful, and often it's just a matter of style which one you use. In fact, the same ES6 update you're talking about also provided the following shorthand syntax for defining non-arrow functions in object literals: Instead of this: { fn: function() {} } I can write this, because of ES6: { fn() {} } They wouldn't have provided this shorthand syntax if they intended arrow functions to replace non-arrow functions all of the time.

[@user-pr1bk5ik2f]

Can I use composition as you described but with classes rather then functions? It's a little confusing - should I choose classes at all? Since functions can be a blueprint that creating objects the same way as classes, and also cam implement the composition we so desire, but currently today, classes cannot. What do you think?

[@JoonhwanLee]

After change object's `name` property, those member function still print out old name.

[@kishorekrish439]

How to filter an object array from 20k records efficient with certain conditions. As of now using like below Let foo = baa.filter(item => item.id == 5)

[@programadordelassombras]

if you needed to track the state of your monster, like hp, health etc., would, you still use this concept, or strictly classes? I am sure there is no one size fits all approach, so I would assume the solution might be a hybrid of both?

[@seyyedkhandon]

Wow that was great😍

[@softwarelivre2389]

But then you are not getting the benefit of propotypal inheritance. Therefore, if you had lots of similar objects, they would probably cause a big impact on performance.

[@wwijsman]

This solves the same problem as multiple inheritence. Python supports multiple inheritence, but I'm not sure if Javascript does.

[@mossasameer3338]

thanks, could you make a tutorial about nodejs cron jobs

[@davitjanashia9344]

Great video thank you... Can you recommend some useful materials on the topic?

[@vario9029]

How can we does that in typescript ?

[@sudarshankj]

To all those comments which are pro-inheritance, this video took an example to display why inheritance might be bad by giving an example. Even one scenario disproving 'Inheritance is the best' clearly indicates that we cannot be binary in our choices, but we ought to be analogous by considering various factors before choosing a strategy.

[@t-time9690]

Every time I think I have a good handle on JavaScript, I find out that there is yet not just one thing I don't know (and have never heard of), there is a whole dictionary of things in JavaScript that I've never heard of. I wonder if JavaScript will change to make all of this obsolete before I can learn these things.

[@sabuein]

Thank you, Kyle.

[@hcr2bangladesh]

i like how beautifully you read the script from the other side , lol

[@evyatarsaar979]

Couldn't be more clear!

[@sebastianbehrens4492]

Or, like in about every other language with inheritence and interfaces, you could use a combination of generic and abstract methods and add concrete methods with interfaces.

[@justsomeguy8385]

Why would you even bring that up when we are talking about JavaScript? Unless you mean he should be using TypeScript, which is hard to disagree with.

[@deltaexile1906]

Despite that "..." is not a deep clone. I still don't figure out how composition take place practically. Classes maybe share the same verb(), but their implementation are much depends on the object's nature self, thus, there much likely happen I have to override again to do the patch. Tho, I believe I missed something, but I just can't tell

[@swimtlvmitnovizki6895]

thank you so much! you r the best

[@jaysonkmendoza]

Well I think this is more mistaking the use case for polymorphism in OOP. Polymorphism is best used when a bunch of classes have the same set of behaviours but execute them differently. It’s not very useful when your child classes are too different than the base class or when the available behaviours are changing over time. If you have behaviours that could change over time then other patterns like the strategy pattern (similar to you used in your example) to hold the algorithm or even data structures of them with the class being sent an action or event that it acts on using the correct strategy.

[@dappinstitute]

Awesome Kyle

[@Pebbw]

Can this apply to other languages besides js?

[@jochenpanjaer980]

Most languages are strictly types (as opposed to JS, which is loosely typed). This means that objects in those languages are more difficulty to change on the fly. But in those cases, you will have access to proper inheritance models and language support for abstract classes and interfaces.

[@omar9987]

Can you explain why depulicating code is not a good idea?

[@hutu2009]

One of the drawbacks is duplication causes poor maintainability. If you want to make one change in a function, you would need to make that change in every duplication.

[@stephenhowe4107]

@3:26: Yes interesting example. But that is because your language does not have multiple inheritance (unlike C++). If it did, you could have these behaviours as mixin's and you would inherit from as many mixins that give the behaviour required. But I am not sure I would go down this road. Then in C++, you have protected and private Inheritance and also virtual inheritance. And only public inheritance gives you type substitutability as per Barbara Liskov's paper. But all of this, is basically modelling and comparing what your language provides with the ability to model your situation in the elements your language provides. And as you say, Composition helps In C++ we have Multiple Inheritance Virtual Inheritance Public, protected private inheritance of data and functions. Virtual functions. Pure Virtual functions. Function Overloading Function Overriding Function Pointers All of this provides a rich set of choices on trying to model situations. Other languages have less and therefore the modelling is harder.

[@adamjohnston3157]

Is there any difference in speed? For example, creating millions of monster objects from a class vs function?

[@soniablanche5672]

javascript classes are functions too. function Person(name) { this.name = name } is the same thing as class Person { constructor(name) { this.name = name } }

[@adamjohnston3157]

Sonia Blanche is it exactly the same though? Not sure. JavaScript is implemented on top of C++. I’m not saying you’re wrong, but looking the same and being the same are two different things.

[@soniablanche5672]

@@adamjohnston3157 yes it's exactly the same, classes are syntactic sugar in JavaScript. JavaScript is still a prototypical object oriented language. You can access the "Class"'s prototype object the same way you do for constructor functions in ES5. class Person { constructor(name) {this.name = name;} } Person.prototype.walk = function() { console.log(this.name + " walked"); } this is exactly the same thing as class Person { constructor(name) {this.name = name;} walk() { console.log(this.name + " walked"); } }

[@adamjohnston3157]

Sonia Blanche nice! I was curious but too lazy to look myself.

[@biswakalyandas8076]

How does your console reflect output as soon as you save

[@jochenpanjaer980]

Live server running, probably. Also check out websites such as codesandbox, codepen or jsfiddle. They do this for you.

[@biswakalyandas8076]

Thanks Jochen

[@avirupduttagupta]

Could you please explain why we need to return ...monster instead of monster? Thank you!

[@asagiai4965]

to return the properties, functions of monster

[@ehsankhorasani_]

with utmost respect that I have to you. The things that your doing as Composition is 100% percent wrong. it's more like multiple inheritance or multiple concatenation than Composition. this is the most misunderstood concept in Javascript Community. I recommend you to take a look to the "Design patterns" book

[@thescottyjam8906]

Yeah... I've been surprised at how many times I've seen this solution come up in blogs and videos among JavaScript programmers, and it's described as "composition". This pattern still carries all of the same problems that multiple inheritance carries, we've just found a way to do it without the class syntax or JavaScript's built-in prototype system. Wikipedia actually categorizes this pattern as a "concatenative prototyping", which, *gasp*, weren't we just trying to avoid prototypes? en.wikipedia.org/wiki/Prototype-based_programming#Concatenation

[@piyushdanej3930]

I guess he is a lil wrong in using the principle of composition in this particular implementation. I feel it is more like multiple inheritance in the way that , the implementation of fly and swim has already been created. And every object created in the shown way gets the same implementation. Can you be more elaborate ? I am curios as to how this is wrong.

[@thescottyjam8906]

@@piyushdanej3930 Like you said, what he's doing more closely follows the idea of multiple inheritance. Composition is really much simpler, you do it all the time, maybe without realizing you do it. All composition is, is taking one object and sticking it on a property of another object. The phrase "favor composition over inheritance" means if you want to share behavior, instead of inheriting from a base class, make a class with your common functionality and have other classes utilize it. If you search for the phrase "composition over inheritance", and look for results in any language but JavaScript, you're sure to find a number of good examples and tutorials explaining it.

[@lucasdantas8754]

ok, i understand this, really cool tbh, but don't we have a problem with this? We are duplicating the methods for each combination we create. i know this is just a simple example, but still we should not be doing this everytime we create a new obj. Using the prototypal inheritance might be better, any opinions on this?

[@olezhonnv3215]

It depends on usecase, sometimes inheritance is good, sometimes composition.

[@songofyesterday]

I feel like composition could be more secure now that I you see explain it, if we inherit a monster class and it could do things that we forgot existed in that class, then we're breaking least privilege principle in security...with composition, you have to tell what that monster can do. It sure looks easier to read too. I'm learning Go right now, newb, but liking this idea of composition over inheritance.

[@xethhung6057]

Thanks for the script shared. But this seems not the problem of inheritance, but the lack of well design facilities of JavaScript for oop. The examples listed can be well achieved in interface or trait in oop language. The advantage of inheritance is that you have a blueprint of the object that you received(object provider always not the object consumer), without inheritance you need to do a lot of stuff for processing object safely.

[@yadneshkhode3091]

Thank you sir

[@ahmedboutaraa8771]

I always thought that brad tarversy is the one but after Watching your tutorials I think you kinda standout

[@voidmind]

Both are really good.

[@brecoldyls]

Yes! This is a video I’ve been wanting, and the example relates to the exact problem I was having. Thank you! 😀

[@brokula1312]

Better example would be: f(g(h(x))); or: flyer(walker(swimmer(monster))); or compose(walker, swimmer, flyer)(monster);

[@DevMeloy]

There is always a few ways to perform the same task, I prefer OOP over a functional programming, and I get the "problem" Kyle is trying to show, properly architected classes wouldn't run into these issues. The biggest issue is that JS is a prototype language with syntactical sugar for classes, moving to a true OO language gives more options to handle different situations.

[@sagarsinghrajpoot6788]

awesome video :) subscribing

[@jamesst8503]

You shouldn't use inheritance, when you are about to use it for the wrong reasons and in the wrong way. A Monster class(or top parent class) must be as abstract as possible, so that no matter what type of monster you are going to create, you need to make sure that its children don't cancel out the parent's properties. Saying that Monster has a method of "walk" means that you assume all types of monsters are able to walk, which is a wrong assumption. Therefore, it might be best for the Monster class to have a method of "move", which is a lot more abstract than "walk" and then it is up to the children to decide on what "type" of movement they are going to have(perhaps by using some interfaces), or perhaps have a property of "name" or "age", which are very abstract concepts for a Monster. Anyway, I don't think inheritance sucks at all, it's people who don't know how to use inheritance effectively that give a bad name to the inheritance concept.

[@RyanValizan]

James St i’ve started to notice a trend with this channel that shows a lot of disinformation - but there is a lot of good information as well. It’s comments like these that help balance out the mishaps of these videos. thanks.

[@RyanValizan]

James St funny, I read your comment, commented, then watched the remainder of the video; after which I then responded to the video with my own comment, to realize after posting it that my conclusion was very similar to yours in that you just need to think more abstract when working with inheritance - and also not be afraid to create new objects within those classes created. such as, “okay, i’m creating an *EvilMonster extends Monster*, what abilities (read, “classes”) will this monster have...move, attack, noise(?),body(fur, type of fur, etc). We are sharing some properties between all monsters but an *EvilMonster* has the special ability to *function attack(direction) {};* which other monsters don’t have. We need to move this monster forward, however, so *evilMonster.move(‘forward’);* calls *public async function move(direction) { return move.direction(); }* - tossed in async, since we’re working with JS in this example, and we would probably have some sort of promise in place waiting for the monster to finish moving before carrying on.

[@michaelmudge3080]

Hey guys, just trying to wrap my head around this whole idea. Isn’t it that it’s just really hard to predict abstraction levels you will need in the future, meaning that some feature request comes a long and in order to implement it you would have to change your abstraction levels which could be a lot of work and break a lot of things, or on the other hand you could just compose your object to mix and match to whatever functionality you need. What are other big advantages to using inheritance ?

[@stevenyeh4975]

@@michaelmudge3080 cannot agree more.

[@emreozgun3846]

@@michaelmudge3080 this is the crux. cheers.

[@TheDiggidee]

You're taking an OOP paradigm (one of the pillars of OOP as well) and tying to apply it to Javascript which is a functional language.

[@steffoqwerty]

can you make it so we can download code ? thnks

[@Gvnrae]

Dude you are awesome

[@consume94]

i think there is a simpler way to explain composition than dynamically creating new objects and adding new methods to them. Overkill for someone looking to get a basic idea into composition?

[@oladipooduola3826]

thank god I found this guy

[@mauro1518]

i don't get it... why did you used - return { swim: () ....}?

[@abdullahimtiaz7696]

Can't you create interfaces of swimming and flying

[@WebDevSimplified]

Javascript does not have interfaces by default and interfaces still require you to implement the method everytime you add the interface.

[@anasaljawa858]

that's amazing

[@kartikmaurya9386]

Will this also be considered functional composition, advantage is that I can add any power to the monster by addPower method: function monster(name){ const monsterPack = { name, addPower: fn => { monsterPack[fn.name] = () => fn(name); return monsterPack } } return monsterPack; } const bite = (name) => `${name} can bite` const fly = (name) => `${name} can fly` const monsterThatCanFly = (name) => monster(name).addPower(fly); const monsterThatCanFlyAndBite = (name) => monsterThatCanFly(name).addPower(bite); const pterodactyl = monsterThatCanFlyAndBite('ptero'); console.log(pterodactyl.fly()) console.log(pterodactyl.bite())

[@hfghfgism]

It seems like to breach liskov substitution of Solid principle the Monster class.

[@rnater7145]

I really hope you're making $$ with this channel. You deserve to!

[@contentprogramming]

sooo good

[@Brofix_]

decorator?

[@Gol_D_Roger_The_Pirate_King]

So basically you are telling me to create a factory function.

[@merovingen4546]

cool, familiar to builder pattern

[@yackawaytube]

In OOP, implementation inheritance is almost always a bad idea. Complex behavior should be derived from composition of simple components, not via implementation inheritance. I learned that first year out of college. The "template method" design pattern is an attempt to deal with a limited case of this problem btw.

[@aammssaamm]

It's still an inheritance but of another class which represents behaviour itself :)

[@pratikzinjurde]

Why Polymorphism is not used in place of composition??