5 ms·
"Inheritance" doesn't really exist in JS. We use that word because we don't have a better substitute, but what Javascript has is simply code sharing. You can sh
by ender7 13y ago
"Inheritance" doesn't really exist in JS. We use that word because we don't have a better substitute, but what Javascript has is simply code sharing. You can share code between multiple objects. This is accomplished by using prototypes. An object has access to all the code defined on its prototype (and its prototype's prototype, and...). If two objects have the same prototype they will have access to the same methods.
Now, unfortunately, the native Javascript way of saying "please set the prototype of this object to X" is not very intuitive. So again we reused an existing word -- "class" -- and defined it to be "a thing that creates an object and sets its prototype to be what I want".
However, actually creating these class things is painful and verbose in vanilla Javascript, so everyone uses a library to do it for them. I use classdef [1] because I wrote it and it works just the way I want it to, but seriously there are a million options out there. Go find one and use it.
[1] https://github.com/7sempra/classdef https://github.com/7sempra/classdef
- tantalor 13y agoI was taught that the practical purpose of inheritance is to share code. Nowadays we call that idea "DRY". Classical inheritance is a means to satisfy DRY. In JavaScript, the same concept exists, and it's sometimes called "prototypal inheritance" (since there are no classes). http://javascript.crockford.com/prototypal.html http://javascript.crockford.com/prototypal.html
- jefffoster 13y agoI've always thought inheritance is used to model is-a relationships. Sharing code may be a side effect, but it's certainly not the reason to use it. Using inheritance to share code is usually better achieved by factoring that code out to a separate object and having the objects in a inheritance relationship use it by composition.
- justincormack 13y agoHmm, interesting view. But why would you want to model is-a relationships? Other than to share code?
- AndrewDucker 13y agoThink of it as enforced documentation. If I say that my object is a Customer then I know what can be done with it. If I have a method that says it takes a Customer object then the calling point knows what to pass in, and my method knows it can rely on that object satisfying certain conditions. Basically it removes (some of) the need to document separately, and it enforces that the documentation is adhered to.
- mistercow 13y agoI feel like, while using classical inheritance in JS is fine, it's an unfair simplification to say that creating classes in vanilla JS is painful. Prototypal inheritance is more powerful than classical inheritance, and the reason it takes a bunch of boilerplate to implement classes in JS is that you're basically narrowing down to a less powerful model. The trouble is that a lot less energy has gone into designing for non-classical prototypal inheritance, and what techniques exist are unknown to most programmers.
- _getify 13y agoI think you'll see in part 3 (should be published tomorrow) why I'm arguing that "objects-only" is the MUCH simpler way to get [[Prototype]] styled code (that is, "behavior delegation"). However, it requires you to stop using constructors and "new" and .prototype and so forth. Part 2 (today) will argue why all those things are actually "distractions" from the simpler model.
- _getify 13y agoI think you're going to see in part 3 (tomorrow) that it actually is quite simple and elegant to define "objects-only" delegation. You have to do away with constructors, "new", .prototype, and all that other stuff, which in part 2 (today) I'm going to argue are just distractions that keep us further from the simple power that is JS's [[Prototype]].