> For the complete documentation index, see [llms.txt](https://ricardomol.gitbook.io/notes/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://ricardomol.gitbook.io/notes/frontend/untitled/oop.md). # OOP ## C**lassical inheritance vs Prototypal inheritance?** ### **Class Inheritance:** **Instances inherit from classes** (like a blueprint — a description of the class) Create sub-class relationships: hierarchical class taxonomies. Instances are typically instantiated via constructor functions with the *`new`* keyword. May or may not use the *`class`* keyword from ES6. ### **Prototypal Inheritance:** **Instances inherit directly from other objects**. Instances are typically instantiated via factory functions or *`Object.create()`.* Instances may be composed from many different objects, allowing for easy selective inheritance. ## **When is classical inheritance appropriate?** Never, or almost never. Certainly never more than one level. Multi-level class hierarchies are an anti-pattern. I’ve been issuing this challenge for years, and the only answers I’ve ever heard fall into one of several [common misconceptions](https://medium.com/javascript-scene/common-misconceptions-about-inheritance-in-javascript-d5d9bab29b0a). More frequently, the challenge is met with silence. Creating **is-a** relationships. ## **When is prototypal inheritance appropriate?** There is more than one type of prototypal inheritance: * **Delegation** (i.e., the prototype chain). * **Concatenative** (i.e. mixins, *\`Object.assign()\`*) * **Functional** (Not to be confused with functional programming. A function used to create a closure for private state/encapsulation). Each type of prototypal inheritance has its own set of use-cases, but all of them are equally useful in their ability to enable **composition,** which creates **has-a** or **uses-a** or **can-do** relationships as opposed to the **is-a** relationship created with class inheritance. ## **Composition vs Inheritance** ## **"Favor object composition over class inheritance”** Quote from [“Design Patterns: Elements of Reusable Object-Oriented Software”](http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612). It means that **code reuse should be achieved by assembling smaller units of functionality into new objects instead of inheriting from classes and creating object taxonomies**. In other words, use **can-do, has-a,** or **uses-a** relationships instead of **is-a** relationships. ## Why you might want to create static class members? Static class members (properties/methods) are **not tied to a specific instance of a class and have the same value regardless of which instance is referring to it**. **Static properties:** typically configuration variables **Static methods:** usually pure utility functions which do not depend on the state of the instance. **References** *