@@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.
@@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.
@@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.
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.
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 !!
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.
@@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.
@@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.
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.
It is possible to manually create an inheritance prototype by using a constructor function and manually setting the methods as prototype methods, right?
@@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.
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.
@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.
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!!!
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!
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)
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
^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.
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.
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.
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/
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 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.
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
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.
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.
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.
@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
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.
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.
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.
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 ?
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
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
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.
@@harkitnebamake 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.
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.
Wait until he learns about TypeScript and how to use interfaces properly. Alternatively, to achieve the exact same result but way more readable, Mixins.
@@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.
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?
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.
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.
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
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.
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.
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.
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.
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
Wait till people trying to justify OOP in comments section discover how OOP and inheritance chains with overly excessive use of patterns in enterprises actually make the code more hard to understand and make the maintainers life a nightmare. That is when you realize using three functions for composition instead of 2 interfaces & 4 classes was a better idea EDIT: Above lessons learned from java experience & never wana go back.
Both inheritance and composition are OOP concepts. Not to be confused with procedural programming or ECS (although in the video he is kind of leaning toward procedural programming, because js allows that). _"Composition over inheritance",_ or *_"has a--,_*_ instead of _*_is a--",_* is a very old advice on how to do OOP. The problem is tutorials online have always been overrun by inheritance, despite that. Probably because in fully OO languages (e.g., Java), composition can be a bit unwieldy (Bob Nystrom has a nice talk about it from that perspective (in Dart): ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-JxI3Eu5DPwE.html ).
@@skaruts you are thinking of a different kind of composition, I meant function composition which is different from composition concept found in OOP. Oh I am a big fan of bob nystrom and his articles on languages and compilers.
@@skaruts thank you for that video, I have no idea why, but it had literally the exact problem i was coming across, with the same exact situation. Lol, it was really perfect, thanks again
LOL. I was looking for a little clarification on the concept in general. I had a coding challenge this morning the goal was to make a player character and to give it abilities by composition. This video pretty much solves my coding challenge lol. Let me know when you are ready Kyle and my character will come slay your monsters ;P
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!
@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.
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.
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.
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.
You are describing interfaces and overloading/overriding (polymorphism) that are available in actual OOP languages. Javascript really isn't designed (fundamentally) as an object oriented language.
@@DEVDerr I love it, especially when you are working with unknown data. Eg, you can tune mongoose queries on the fly because the $match and $group objects are json objects. Or add custom flags and functions to existing components (eg authorization tokens).
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.
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?
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.
Inheritance shouldn't be used with the purpose of reusing existing implementation code. Its purpose is to handle all similar objects in a similar way. Check Liskov substitutability principle. It basically becomes like interfaces. In your example, there might still be a need to handle all monster objects in a similar fashion, without knowing if it can fly/swim etc, like obj.takeAction() or something. Point is you'd need both inheritance and composition for different reasons.
Great video. No body is gonna invent the wheel in 2020. After dozens of years of programming, OOP has become one of the best ways to keep code clean and functional. What you are doing can be achieved in many languages with decorators or traits. Anyway, the video is a good tip for those who hate oop.
JS has decorators and these actions could be simply injected to specified classes, but still... you need to make some boilerplate code to just run this. Functional-composition approach doesn't require any boilerplate. They're just simple functions that can be passed to any other function you want.
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.
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?
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?
The problem with JavaScript is that it tries to emulate an oo programming language without enforcing the strict rules an oopl requires, and that causes a whole bunch of people to corner themselves in situations like this one, but that's a sacrifice you have to make if you want js to also be a functional language. In true OOP languages you can simply fix this with interfaces (or multiple inheritance obv, but most languages don't allow that), something javascript doesn't have, because it is also a functional language, which mind you does a better job at fixing these problems. With that in mind, this is exactly why prototypes exist, use them, don't spaghetti code your way around it.
i don’t get it. Why wouldn’t* the monster just get a class of actions and a class of movements? Composition looks like it will get sloppy very quickly, and should only be considered for 1 off situations. Take this example based on what you showed. For Action Class: An action class would have been assigned as *const action = new Action()* when the *SwimmingMonsterCreator* class was constructed. To have the monster attack, you would call a a method like *monster.attack();* which would use *return action.attack(‘monster’);* to attack something. For Movement Class: A movement class would have been assigned as *const move = new Move();* when the *SwimmingMonsterCreator* class was constructed. To have the monster: walk would be *monster.walk(‘direction’);* which would call *return move.walk(‘direction’);* swim would be *monster.swim(‘direction’);* which would call *return move.swim(‘direction’);* fly would be *monster.fly(‘direction’);* which would call *return move.fly(‘direction’);* This keeps all of your actions and movements contained to a class. there is no reason a better thought out inheritance structure wouldn’t be superior in this situation. You’re literally just created a serious of methods outside of a class where they can be misplaced, forgotten about, or, worse yet, repeated with no ability to have common properties between them all which walk, run, job, may all have as movement methods in the Move class. *edit* I already seen areas for improvement in my example scenario and it’s not bug free, it’s concept..okay? *monster.move(‘style’);* may be a better method. which then can use maybe a switch statement to call the *move.style();* this would eliminate the need to repeat all of the methods from the action class required for the monster.
It doesn't mean inheritance is bad, but just JS does not support multiple inheritance. Using a factory pattern without any classes ruins the auto-completion in IDE and requires more human memory to use them
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'.
This can only be applied to functional language like javascript right? For language which requires classes to be strictly defined (e.g. Java) seems cannot use this trick😅
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?
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.
javascript classes are functions too. function Person(name) { this.name = name } is the same thing as class Person { constructor(name) { this.name = name } }
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.
@@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"); } }
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?
You can also create just one general class for all of them (in your example, Monster) and assign every new Monster you create a default value for whether they can swim, fly... in the constructor by //this.swimmer = false//, etc. Then you can create the function for swimming, flying... inside your class definition and make it only work if //this.swimmer == true...// And finally if you want to create a new kind of monster you can simply create a new function which just create a new Monster and set its .flyer or .swimmer = true and then return that monster. It might look like: class Monster { constructor(name) { this.name = name; this.attacker = true; this.walker = true; this.swimmer = false; this.flyer = false; walk() { if (this.walker == true) { console.log('${this.name} walked') } } // And so on with the other functionalities function swimmingMonster(name) { newMonster = new Monster(name) newMonster.swimmer = true return newMonster } I implemented this myself in python for creating matrices and vectors (I created the Matrix class and then added a function vector() which creates a new Matrix with the specific properties a vector needs [vectors are just a special type of matrices] and completely compatible with matrix mult, addition and so on) and it works quite well. PS: sorry for such a long comment, I hope it may be useful
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?
If you dig deep then you will observe that Object created via this function: function flyingSwimmingMonsterCreator(name){ ... } will have two different states. The object const monster = {name: name} returned from the function will be a copy of the which is inside of the function, while the object that is passed to the functions swimmer(monster) and flyer(monster) will refer to the object inside of the function. So if you create a function to change the name then on console.log(obj.name) we will not get the updated name. (obj is an object created from flyingSwimmingMonsterCreator) but if we also have a function to print the name, then it will print the update name.
so instead of destructuring, if you want to maintain consistency in the properties use Object.assign. i.e. function flyingSwimmingMonsterCreator(name){ const monster = {name:name}; return Object.assign(monster, swimmer(name), flyer(name)) }
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.
JS does not have interfaces. Example about monsters is not correct. Inheritance problem is not described in this example. Composition can be done in OOP, but this example doesnt cover that.
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?
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
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?
