# 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.&#x20;

## 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**

* [https://stackoverflow.com/questions/21155438/when-to-use-static-variables-methods-and-when-to-use-instance-variables-methods](https://stackoverflow.com/questions/21155438/when-to-use-static-variables-methods-and-when-to-use-instance-variables-methods)

