Writing Better Javascript Classes and modules

Classes are something that took me a minute to understand why I needed them compared to simply using object literals.

let person={
  name:"kwame";
  age:45
}

Object literals were easy to create and less ambiguous to write.
It was all rainbows and chocolate until I wanted the objects I created to share features and to reduce redundancy in the code I wrote. I started writing classes for this and I was happy per say. Some redundancy still remained until I read about the second letter of the SOLID principle, Open-closed principle

OPEN-CLOSED PRINCIPLE

If you have been writing JavaScript for more than 3 days then you have used this principle before. Shocking right? Well, I guess that's the cool thing about JavaScript. My favorite definition of this principle is by Bertrand Meyer.
"A software artifact should be open for extension but closed for modification."

Let's break down this statement's key words.

1. software artifact may mean a lot of things but in this context take a software artifact as a module or a class.

2. open for extension. This generally means that your class or module should allow the ability of a user (by user I mean the programmer using that class or module) to create new features for his program using the functions or methods from classes or modules.

3. closed for modification. This the twist of the Bertrand's definition that makes me love it very much. Well, since our classes have multiple features the programmer would love to use, the implementation of these new features should not involve the programmer re-evaluating the parent class and making tweaks to it.

Khalil Stemmler expanded on this by saying
"Write your code in a way that if you want to add new functionality you don't rewrite the existing code"

If a user wants to change how a certain method is implemented in the parent class then they should simply override the method.
Overriding simply means re-writing a method from the parent class to the daughter class.
For instance, let me create a class Animal

Class Animal{
 walk(){
 console.log("Hop")
 }
 eat(){
 console.log("Chew very loudly")
 }
}

our animal has two behaviours. Eating and walking.
My chicken has these two behaviors but how my chicken does these two behaviors is different. Firstly, it doesn't hop and it doesn't chew very loudly.
Well by tweaking my animal class to match these chicken characteristics then all should be fine. But this is not the best approach because what if I want to add another animal let's say a puppy? we cannot have our puppy show the characteristics of a chicken.
Here is where the open-closed principle swoops in as our knight and shining amour to save us from bad code.
The chicken class will simply override the characteristics of our animal. That way the open/closed principle will not be broken.

class Chicken extends Animal{
 walk(){
 console.log("on two legs");
 }
 eat(){
 console.log("crow after eating a seed")
 }
 sleep(){
 console.log("on the roof")
 }
}

The chicken class was able to add new features without needing to modify the animal class.

Closing thoughts.

This is part two of a series. I would recommend checking out the previous blog post.
This rule helps you write better modules and classes. A good programmer doesn't follow all the principles of code but knows when to use the right principle and when to not follow another principle.