Javascript Object Composition is preferable to inheritance for keeping your code clean and D.R.Y. In this tutorial, we'll look at examples of some problems with inheritance and how composition can solve those problems. In addition, we'll look at an easy mistake to make when you are working with data structures in objects, and how to avoid that mistake. This is a more advanced tutorial. If you're just starting with Javascript, I suggest checking out my 8 hour full course tutorial on Javascript here: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-EfAl9bwzVZk.html 🚀
I've been looking for a JS tutorial were I could focus on more advanced topics, now that I (believe I) have the foundations. This is gold, been following this tutorial and I'm amazed with the quality of the explanations and the concepts you bring - of which very few I knew before. Thanks a lot, I very rarely leave youtube comments but I felt in the need to thank you for this. I am learning so much!
whe u give an object which extends other obejct and u create function which takes and object as parematr and return objects with methods that u want it doesnt really extends the methods from extended class idk why but it doesnt ts just return an object with ur given methods
Awesome content! Subscribed. Correct me if I'm wrong, but there is a slight issue doing it this way. Every time you call the create method, those methods are not going to be added to the prototype but the object itself. As a result, if you create two pizzas using createPizza, it will create prepare, bake, and ready twice per object. If it was on the prototype, those methods would be created once and shared among the two pizzas.
Thank you! Good discussion, but I disagree with composition causing an issue. If you added a method to a prototype - you are once again going back to inheritance. Adding a method to a prototype is like including a method in the createPizza factory function. Both the prototype and the factory function would pass along that method to ALL objects that were created from that base. The other functions (composition) are compared to the extending classes using inheritance.
@@DaveGrayTeachesCodeDave, Thanks for the response. I totally agree with you about choosing composition over inheritance. Maybe I wasn't clear. When creating a function constructor and wanting to add a method to that function constructor, it needs to be added to its prototype from an efficiency standpoint and save memory. By doing so, each instance can use the same method and not create the same method for each instance created (I'm sure you know all of this). My question and concern were about object literals and adding methods to them. When adding a method to an object literal, does it have the same effect? Do we have to worry about memory when dealing with object literals and adding methods to them? I hope that was clear.
I understood overall although I was talking more about design and DRY principles than concern of memory usage - which I now understand was an underlying concern as well. A good article by Eric Elliot on this topic ( medium.com/javascript-scene/why-composition-is-harder-with-classes-c3e627dcd0aa ) A quick quote from the article: "The [[Prototype]] link is used for prototype delegation, which is a convenient way to conserve memory if you have millions of objects, or to squeeze a micro-performance boost out of your program if you need to access tens of thousands of properties on an object within a 16 ms render loop cycle. If you don’t need to micro-optimize memory or performance, the [[Prototype]] link can do more harm than good. "
I get exactly what ur doing, but curious why we just don't pass in a spread'd object to prevent this mutation, ala ``` var origObj = { age: 99, name: 'bill' } function test(w) { w.attribute = true; return w; } console.log(test({...origObj}), origObj); ```
One caveat is you're creating multiple times the same method. if you don't need to make closures and they're meant to persist, you can change function butter() { return () => console.log("Buttering the crust..."); } { ...butter() } into function butter() { console.log("Buttering the crust..."); } { butter } to save on memory
Good question - The suggestion here is to use composition instead. The existence of inheritance is not enough to justify its use. The only reason(s) I can think of where I would use it: 1) You are assigned a legacy code base that uses it or 2) You're on a team that is already using it, so it isn't your choice.
Yes Composition is flexible, but it is too verbose, you have to create every function separately on its own, and then use it to compose something bigger, which when the project gets bigger is hard because you will have too many functions that you don’t know anymore how to use them or what uses them. However, with OOP, you have everything needed in a single place (the class). In short, OOP offers abstraction and encapsulation, which composition clearly lacks. (And I didn’t even mention how you will suffer when you type all these composition functions, you will have to describe the type of every single return type which gets too complicated and too much very fast.)
Hey Dave, big fan of the content. I created maybe a more simple implementation below. let addToppings = (pizza,toppingArr) => { return Object.assign({},pizza,{toppings:toppingArr}) } const davePizzaWithToppings = addToppings(davesPizza, ['olives','cheese'])
05:26 - I can see whay does the pizza (AS AN OBJECT?) gets a prefix of a spread operator, But why do the functions get it as well? - Each function is being called only once for each pizza object, So what is the reason that the spread operator comes before them as well?
Hi Dave, I need your help please...you are my primary source of learning! I'm building a serious personal project in React right now, and I'm unsure whether to use inheritance in my program. It's a Boxing Simulator where the user creates an account, which generates a Boxer with 20 attributes of random value. On submission, 30 random boxer-opponents are generated and everything is persisted on the cloud. Boxer profiles, { conditioning, strength, speed, agility, chin, ...others }, Wins, Losses, a ranking system, charts for body and head damage, a full 12 round fight etc...a LOT. Since the "inherent" properties are consistent, is it bad convention to use classes (class constructor) with said web app? Or should I construct my "boxer objects" with full composition, and just have a laundry list of attributes as my arguments? And do I store this as "helper" functions or under a "businessLogic" component? Thank you so much, I've been following you since November of last year!
Hi Marcus, good questions - and much of the answers are based on personal preference. From this tutorial, you can tell I prefer composition. That said, if you prefer to use inheritance, it is not considered "bad", it is just your preference. You mention you are using React. Your app structure could vary greatly depending on what you are using with it - Context? Redux? React Query? Other state management? etc. - without knowing much about your project, I don't think you would be creating all of those objects within a component. Instead, you may be tracking them with some state as mentioned above.
Does anyone know how to make methods or properties private when using composition? Using classes you would prefix the property or method with # making it available only internally
You could use closure: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-1S8SBDhA7HA.html Create a variable that holds a value or function only accessible to the method returned.
I have a solid foundation of knowledge of JavaScript - I honestly love your vids - I always enjoying finding new more advanced ways of working with code - happily subscribed
Usually some say one shouldn't be "opinionated" about one's approach to code, but here you clearly showed how composition owns inheritance in any way, and I wonder what those people could say as a counterargument. You enlightened us in this topic. Thank you, dear mentor. Just one wish: in one comment here you replied about the real use case of inheritance (which again composition owns it whenever its use is possible), I hope it was included in the video as well, as a summary or so.
Hey Dave it seems that source code on github is missing 12:50 onwards. I don't need it but maybe someone in future might need it. and thanks for making great tutorials.
Concise and on point. I love it. P. S writing a one liner code is a creative experience in itself. Condensing code into is most core form. Kind of like this video actually
This is more of an app architecture question, but a good question at the same time. It really depends how your app is structured, but yes, I would say overall, you will want to have some sort of closure over an architecture so globals are not an issue for a variety of reasons. 🚀
Sadly the real life example makes things worse. On this example it seems good, but pizza composition is really not the use cases we face. I think you went to this example, because OOP wants to model real world objects, but then the critizismn is that this is not the way. Obviously even if you code with OOP, you would never create a pizza like that and add functions like toppings.
Thank you! 🙏 Good question! At 8:51, I see I was creating an object. In this example, a pizza object needed to be passed in (inside) rather than chained. A little bit later at 9:12 when calling methods, the examples I give will not chain because the methods do not return a result, they just log to the console. You can try to chain the bake() and stuff() methods to see what I mean. The 2nd method cannot call on undefined. If bake() were to return an array for example, you could then chain the array reverse() method to it.
Dave when you do return { ...pizza,...prepare(),...bake(),...ready()} you spread the pizza object and all this function in one object. I find it interesting because I've never seen function being spread
@@DaveGrayTeachesCode I forgot to say thank you for your work :-) but now I will use the spread operator to clone function in an object when i need it and by the way is it a deep copy I mean if I change the original function will it affect my clone function ?
@@soniamaklouf1178 the spread operator does not make a deep copy. More on deep copy vs shallow copy here: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-4Ej0LwjCDZQ.html
I am going by memory here without looking at a specific timestamp, but you can add properties to an object using dot notation instead of adding them in a constructor. That is likely what I did.
@@DaveGrayTeachesCode the code i'm referring to is in 0:23, line 6. Well, yes, I know I can add but, the question is, why? Why you did that? Is there any reason to be doing this? Is there like, some particular reason or need or goal to do this?
Hey, thanks for being patient as it has taken me a few days to reply. I created a gist on GitHub for you with the source code: gist.github.com/gitdagray/e3452b267fffb05ee25f0166ab15511f
Thank you for impacting such detailed knowledge. Just a humble feedback. I m not a pizza person, I was trying to wrap my head around the pizza example and i kind of got lost in it for a few minutes. Maybe u can use a more relatable example asides pizza in more Videos ahead. Thank you Dave💪
