As we'll see later, doing so in your JavaScript code is opting into frustration and code brittleness. In fact, relative polymorphism lets us reference the base behavior from the overridden behavior.Ĭlass theory strongly suggests that a parent class and a child class share the same method name for a certain behavior, so that the child overrides the parent (differentially). While Vehicle and Car collectively define the behavior by way of methods, the data in an instance would be things like the unique VIN of a specific car, etc.Īnd thus, classes, inheritance, and instantiation emerge.Īnother key concept with classes is "polymorphism", which describes the idea that a general behavior from a parent class can be overridden in a child class to give it more specifics.
The definition of Car is said to specialize the general Vehicle definition. Instead, we define that capability once in Vehicle, and then when we define Car, we simply indicate that it "inherits" (or "extends") the base definition from Vehicle.
It might not make sense in our software to re-define the basic essence of "ability to carry people" over and over again for each different type of vehicle.
What we define in Vehicle is all the stuff that is common to all (or most of) the different types of vehicles (the "planes, trains, and automobiles"). The definition of Vehicle might include things like propulsion (engines, etc.), the ability to carry people, etc., which would all be the behaviors. We model this relationship in software with classes by defining a Vehicle class and a Car class. A car can be described as a specific implementation of a more general "class" of thing, called a vehicle. Let's explore this classification process by looking at a commonly cited example. The way we do this is to think about any given structure as a specific variation of a more general base definition. But you almost never just care about the data, you usually want to do things with the data, so the behaviors that can apply to that data (calculating its length, appending data, searching, etc.) are all designed as methods of a String class.Īny given string is just an instance of this class, which means that it's a neatly collected packaging of both the character data and the functionality we can perform on it.Ĭlasses also imply a way of classifying a certain data structure.
This is sometimes called "data structures" in formal computer science.įor example, a series of characters that represents a word or phrase is usually called a "string". OO or class oriented programming stresses that data intrinsically has associated behavior (of course, different depending on the type and nature of the data!) that operates on it, so proper design is to package up (aka, encapsulate) the data and the behavior together. "Class/Inheritance" describes a certain form of code organization and architecture - a way of modeling real world problem domains in our software. But there's a lot of concept and pseudo-code to wade through first, so don't get lost - just stick with it! Class Theory We eventually relate these ideas to real concrete JavaScript code in the second half, when we talk about "Mixins". Note: This chapter spends quite a bit of time (the first half!) on heavy "objected oriented programming" theory. We'll see that these concepts don't really map very naturally to the object mechanism in JS, and the lengths (mixins, etc.) many JavaScript developers go to overcome such challenges. We'll first look at "class orientation" as a design pattern, before examining the mechanics of "classes": "instantiation", "inheritance" and "(relative) polymorphism". Please ignore this stuff.įollowing our exploration of objects from the previous chapter, it's natural that we now turn our attention to "object oriented (OO) programming", with "classes". You Don't Know JS yet: Objects & Classes - 2nd Edition Chapter 4: Mixing (Up) "Class" Objects NOTE:Įverything below here is previous text from 1st edition, and is only here for reference while 2nd edition work is underway.