DEV Community: Adhiraj Kinlekar

Inheritance vs Composition vs Aggregation

Adhiraj Kinlekar — Fri, 19 Jan 2024 14:03:50 +0000

The process of forming relations among entities is a crucial aspect of system design, playing a pivotal role in shaping the overall structure and functionality of a system. In the context of system design, entities represent distinct objects or concepts within the domain of the system.

To facilitate a deeper understanding of these relationships, let's explore the concept of association. Association is a technique for creating relationships between classes, where one class contains a reference to another class or object. This concept is fundamental to how entities interact, communicate, or collaborate within the system.

Aggregation

Aggregation is a weak form of association, where the contained class can exist independently of the containing class. The containing class is said to have a "has-a" relationship with the contained class.

In the given example, the Engine object is not "owned" by the Car class; rather, it's passed to the Car class through its constructor. The Car class simply holds a reference to the Engine object. The Car class doesn't control the Engine object's lifecycle. If the Car is destroyed, the Engine can still exist independently.

    public class Car 
    {
        private readonly Engine engine;

        public Car(Engine engine) { this.engine = engine; }

        public void Move() { engine.Start(); }

        public void Stop() { engine.Stop(); }
    };

    public class Engine
    {
        public void Start() { /* code to start the engine */ }

        public void Stop() { /* code to stop the engine */ }
    };

Composition

Composition, on the other hand, is a stronger form of association, where one class contains a reference to another class, and the contained class cannot exist independently of the containing class.

The containing class is said to have a "part-of" relationship with the contained class. For example, the Address class is associated with a particular user and cannot exist independently.

In composition, the class object's life cycle is fully controlled by the containing class, meaning when the containing class is destroyed, so is the contained class.

    public class User
    {
        private readonly string name;

        private readonly Address address;

        public User(string _name, int houseNo, string city, string state) { 

            name = _name;

            address = new Address(houseNo, city, state);
        }

        public string GetBasicUserInfo()
        {
            return name + " " + address.state;
        }
    };

    public class Address
    {
        public readonly int houseNo;

        public readonly string city;

        public readonly string state;

        public Address(int _houseNo, string _city, string _state)
        {
            houseNo = _houseNo;

            city = _city;

            state = _state;
        }
    };

Inheritance

Another related concept in forming relationships is inheritance. Inheritance is a fundamental concept in object-oriented programming (OOP) that allows a class (called a subclass or derived class) to acquire properties and behaviors (fields and methods) from another class (called a superclass or base class).

Inheritance establishes an "is-a" relationship between the base class and the derived class. For example, if you have a base class User and a derived class Employee, you can say that "an employee is a user".

    public class Employee : User
    {
        public readonly int employeeId;

        public Employee(int _employeeId, string _name, int houseNo, string city, string state) : base(_name, houseNo, city, state)
        {

            employeeId = _employeeId;
        }
    }

In conclusion, the establishment of relationships among entities is at the core of effective system design. By defining connections and associations, we enable entities to interact, communicate, and collaborate within the system. It's crucial to recognize that the way entities are related has a profound impact on the system's efficiency, data integrity, and overall performance.

Song of the day: The Dear Hunter - The Most Cursed of Hands / Who Am I

What makes a database ACID compliant?🧪

Adhiraj Kinlekar — Mon, 20 Nov 2023 08:45:38 +0000

Before diving into ACID, let's first establish a fundamental concept in database management: transactions. A database transaction is a logical unit of work that consists of one or more operations executed against a database. It's worth noting that, in most databases, a transaction is always initiated, with each individual database operation treated as a transaction. Users can explicitly start one, and if a transaction is not explicitly started, the database system will automatically start it and then promptly conclude the transaction.

Now, turning our attention to ACID, which stands for Atomicity, Consistency, Isolation, and Durability, it represents a set of properties that ensure the reliability and integrity of data within a database system.

1. Atomicity

Atomicity is a fundamental attribute of transactions, emphasizing their indivisible nature. Transactions, consisting of a set of operations, either successfully complete in entirety or undergo a complete rollback in the event of failures, such as power outages, exceptions, or crashes. This ensures that the database remains in a consistent state despite unforeseen challenges.

Let's consider a simple example of an atomic transaction in a banking context:

Suppose you want to transfer money from one account to another.

Debit:
Deduct $100 from Account A.

Credit:
Add $100 to Account B.

In an atomic transaction:

Both the debit and credit operations must successfully complete, resulting in Account A being debited by $100 and Account B being credited by $100.

Or, if any part of the transaction fails (e.g., Account B is inactive), the entire transaction is rolled back. In this case, no money is deducted from Account A. This ensures that the bank account system remains in a consistent state, and the money transfer is treated as an indivisible unit. If something goes wrong, the system won't end up in an inconsistent state where money is deducted from one account but not added to the other.

2. Isolation

It refers to the ability to concurrently process multiple transactions in a way that one does not affect another. Changes occurring in a particular transaction will not be visible to any other transaction until that specific change in that transaction has been committed.

Isolation levels define the degree to which a transaction must be isolated from the data modifications made by any other transaction in the database system.

A transaction isolation level is defined by the following phenomena –

Dirty read - A dirty read is a situation when a transaction reads data that has not yet been committed.

Non repeatable read - A non-repeatable read occurs when a transaction needs to read the same row twice, and there is a mismatch between the values in these rows.

Phantom read - A phantom read occurs when a transaction reads a set of rows satisfying a specific condition in a read query, and another transaction inserts new rows that would meet the condition specified in the aforementioned read query. As a result, upon subsequent reads, the result will include new rows that were not present in the initial read.

Lost update - It occurs when a same record is updated by two different transactions at the same time.

Isolation levels in database transactions vary depending on these phenomena, and the following are some examples -

Read Uncommitted :
Read Uncommitted is the lowest isolation level. In this level, a transaction can read changes made by other transactions, regardless of whether those changes have been committed or not. At this level, transactions are not isolated from each other. This isolation level does not prevent dirty reads, non-repeatable reads, or phantom reads and it is susceptible to lost updates.

Read Committed :
This isolation level guarantees that any data that is being read in a transaction is committed. The transaction secures a read lock (for read-only operations) or a write lock (when updating or deleting the row) on the current row to block other transactions from modifying or deleting it. The read locks are released as the transaction moves away from the current row. It holds write locks until it is committed or rolled back.

Repeatable Read :
This is one of the most restrictive isolation level. Beyond the assurance of encountering only committed data, any rows read by a transaction remains constant throughout subsequent reads within the same transaction. The transaction enforces read locks on all rows it accesses and write locks on any rows subject to insertion, updating, or deletion. The transaction releases its locks when it is committed or rolled back. This effectively prevents issues like dirty reads, non-repeatable reads, and helps mitigate the risk of lost updates. However, it's important to note that phantom reads remain a possibility.

Serializable :
It is the highest level of isolation. Serializable isolation ensures that transactions are executed in a manner that maintains serializability. This is the strongest of all the isolation levels and guarantees pure isolation. The transaction holds a read lock (if it only reads rows) or a write lock on the range of rows it affects. For example, if the transaction includes the SQL statement DELETE FROM Orders WHERE Status = 'PLACED,' the range is all rows with a Status of 'PLACED'; the transaction write-locks all rows in the Orders table with a Status of 'PLACED' and does not allow any rows to be inserted or updated that match this condition. Serializable isolation prevents dirty reads, non-repeatable reads, phantom reads, and prevents lost updates.

Snapshot :
In Snapshot Isolation, each query in a transaction only sees changes that have been committed up to the start of the transaction. It is considered an optimistic form of concurrency control because it allows transactions to proceed with the optimistic assumption that conflicts are rare. The transaction itself will only succeed if none of the updates it has made conflict with any concurrent updates made since that snapshot. Snapshot isolation prevents dirty reads, non-repeatable reads, phantom reads, and prevents lost updates.

It's worth noting that the implementation of the isolation levels can vary across different database management systems. The details mentioned here are tailored with Microsoft SQL Server in mind.

Let's consider a scenario where isolation is not maintained, leading to a "dirty read" in a banking context:

Transaction 1 (Jane):
Jane initiates a transaction to transfer $100 from her account to John's account.
Transaction 1 has not been committed yet.

Transaction 2 (John):
John initiates a transaction to check his account balance.
John's transaction reads the account balance, which includes Jane's uncommitted transfer.

Now, due to the lack of isolation:

John sees an updated balance in his account, reflecting Jane's transfer, even though Jane's transaction has not been committed.
The problem: John has read uncommitted data, leading to a "dirty read" where he observes changes made by Jane that are not finalized. In the event that transactions do not reach completion, it can result in significant confusion and potential discrepancies.
This example illustrates the potential issues that can arise when transactions are not properly isolated, allowing one transaction to see uncommitted changes made by another transaction.

3. Consistency
Consistency refers to the correctness and integrity of a database's data during and after a transaction. when transactions are being processed or executed within the database system the data should not be inconsistent and should always be in valid state. The “valid state” refers to the rules specified such as integrity, referential, not null, data types or other SQL constraints. To ensure consistency, database operations must be atomic, and transactions must be isolated from one another and if data at any stage goes against the specified rules or constraints, the whole transaction should fail.

We should not mistake strong/eventual consistency with the consistency guarantee of ACID databases. Strong/eventual consistency refers to the degree of consistency across multiple nodes of a database system. However, when replications are performed asynchronously (changes are not applied to all nodes immediately, and the primary database commits transactions without waiting for acknowledgment from replicas), it can introduce a delay between the time a transaction is committed on one node and when it is replicated to other nodes. During this lag, there is a window of time when the data on the replicated nodes may not be consistent with the source node.

4. Durability

Durability ensures that once a transaction is committed, its effects are permanent and survive any subsequent failures, such as power outages, system crashes, or errors. The changes made during a transaction are written to durable storage, such as a solid-state drive, ensuring permanence even in the case of failures.

This durability is commonly achieved through mechanisms like transaction logging, where changes are initially recorded in a log stored on durable storage before being applied to the database. The transaction log serves as a record for recovery in case of failure. When the system is restarted or recovered, the committed changes are still present, and the DBMS uses it to recover the database to a consistent state by applying all committed changes.

Song of the day: Dream Theater - Pull Me Under

Git Essentials: A Pragmatic Approach to Version Control 🌿

Adhiraj Kinlekar — Sun, 12 Nov 2023 19:24:50 +0000

Introduction to Version Control

👋 To understand Git, having a foundational understanding of version control is essential. Version control, also known as source control, is the practice of tracking and managing changes to files over time. Version control systems are software tools that help software developers work in a team by enabling efficient collaboration and effectively managing changes to files in projects. By far, Git is the most widely used version control system in the world today.

Introduction to Git

Git is an open-source distributed version control software originally developed in 2005 by Linus Torvalds. To get started with Git, download and install it from git-scm.com. During installation, use the recommended settings and optionally select a default editor of your choice. Once installed, the next step is to create a Git repository.

Creating a Git Repository

A Git repository is a directory whose contents are tracked by Git. As a good practice, always execute git status to confirm you are not currently within an existing repository before initializing one. Utilize the git init command to create a new Git repository or convert an untracked project into one.

Working with remote Repositories

Git repositories can be either local or remote. When collaborating on an existing project hosted on a remote server, you can duplicate the repository in your local directory. The process of creating this local copy is known as cloning. Here's an example:

git clone https://github.com/facebook/react.git

Staging and Committing changes

Once your repository is cloned or initialized, add a file or make some changes to existing files to understand some of the most important concepts in Git, staging and committing.

Committing: Saving a Snapshot of Your Codebase

Staging is a step that comes before committing, but before diving into it, it's helpful to first understand what committing entails and what problems it addresses.

Imagine investing considerable time and effort into developing a feature, only to encounter an unexpected event just before completion, potentially resulting in the loss of your code changes. While periodic file-saving provides some protection, it may not be foolproof. This is where Git comes into play. Committing in Git serves as a mechanism to save and undo changes as well as offers the ability to restore previous code versions.

Committing essentially acts like taking a snapshot of your codebase at a specific moment. By committing changes, you create a record of your codebase's state, providing a reference point for future use. This practice ensures the safety and recoverability of your work, allowing you to navigate through different versions of your codebase with confidence

Staging: The Pre-commit Step

So, where does staging fit into this? 🤔 Staging plays a crucial role in the Git workflow, enabling you to specify which local changes should be included in the next commit. When you stage changes, you effectively add modified files to the staging area, preparing them for inclusion in a commit.

It's essential to understand that staging itself does not make any permanent changes to the repository—only committing records the changes permanently. To maintain clear and organized commits, it's a good practice to group related changes together when committing.

Here's an example of adding a file to the staging area and performing a commit with a message:

// Add a file to the staging area
   git add <filename>

// To commit the changes to the repository with a message
   git commit -m "Added a new file to the project"

Branching in Git

One of the most important features of a version control system is its capability to create branches, allowing developers to simultaneously work on different versions of the code.

A branch represents a distinct version of the codebase derived from a specific point in the repository's history. This new version, essentially a snapshot of the code at the time of branching, enables developers to work on new features, experiment with code changes, or address bugs without impacting the main codebase until ready for integration.

The master branch is the default branch created upon initializing a repository. Typically, it functions as the primary branch where all changes eventually merge from other branches. While the master branch is commonly employed for production code, its usage can vary based on the team's development workflow and practices.

The git branch command offers various functionalities, including creating, listing, renaming, and deleting branches. To create a new branch based on the current working branch, simply execute the following command:

git branch branch-name

Navigating between branches

The git checkout command provides a way to switch between branches. However, it's worth noting that this command has multiple uses, and hence it is a good practice to use the newer, safer and appropriately named git switch command.


git checkout feature-branch

git switch feature-branch

Now let's see how we can navigate between branches without having to discard local changes…

Stashing

Stashing is used to record the current state of the working directory and go back to a clean working directory. The command saves your local modifications away and reverts the working directory to match the HEAD commit.

Quick note - (In Git, the HEAD typically points to the latest commit on the currently checked-out branch. In a detached HEAD state, it directly references a specific commit rather than a branch. To reattach the HEAD, simply switch to a branch. To discard changes made in this state, checkout to an existing branch. Commits in a detached HEAD state won't impact the existing branch and are archived by Git. To retain changes, create a new branch, and the HEAD will no longer be detached)

Stashing is handy when you need to quickly switch between branches and work on something else, but you're mid-way through a code change and aren't quite ready to commit. A commit is part of the public Git history, meaning that other collaborators can see your commits when they fetch or pull changes from the repository. In contrast, a stash is stored locally on your machine and is not automatically shared with others.

The most common git stash options include:

git stash push // creates a new stash, rolling back file states.

git stash pop // restores stash files to the workspace and deletes the stash.

git stash apply // restores stash files to the workspace without deleting the stash.

git stash list // shows stash history chronologically.

git stash clear // removes all stash entries.

Undoing and managing history

Git provides multiple ways to view and amend history. You might want to amend history in case something goes wrong or if you want to clean up unnecessary commits and have a clean history.

Git restore

The git restore command is used to unstage or discard uncommitted local changes. It can undo the effects of git add with the --staged argument, allowing you to unstage changes previously added to the Staging Area. Additionally, it can discard local changes in a file, reverting it to its last committed state."

Git reset

The git reset command resets the repository back to the specified commit. Changes from commits since the specified commit will be preserved as unstaged changes, allowing you to take further action as needed. It also offers a more forceful option, --hard commit-hash, which not only removes commit entries but also discards all changes made since the specified commit.

Git revert

Another useful command related to undoing history is the git revert command. It creates a brand new commit that reverses the changes from the provided commit. For this reason, git revert is commonly recommended for undoing changes on a public branch to avoid confusion and potential conflicts when pulling changes. On the other hand, git reset should be reserved for undoing changes on a private branch.

Collaborating with other developers

In a professional environment, your source code is likely to be stored in a remote repository that is connected to your local repository. Remote repositories are hosted on platforms like GitHub, GitLab etc. Developers work together by regularly pushing and pulling changes to and from the remote repository. This allows multiple people to work on the same codebase and share their contributions. The remote repository acts as a central location for the team to keep their code and collaborate efficiently.

Git Push

Pushing is the process of uploading the content of a local repository to a remote repository. It facilitates the transfer of commits from a local repository to a corresponding remote one, such as on GitHub. Git allows you to set the upstream of the branch being pushed, creating a linkage between the local branch and its counterpart on the remote repository. Once the upstream is established for a branch, you can conveniently use a shorthand command to push the current branch to its upstream, eliminating the need to specify the remote or branch explicitly.

Quick note - (Upstream refers to the original repository or branch from which a clone or fork was created. For example, when you clone a repository from GitHub, the remote GitHub repository is considered the upstream for the local copy. Pushing changes to a branch that doesn't exist remotely creates a new branch on the upstream repository. The terms 'origin' and 'upstream' are interchangeable, representing the repository from which the project was cloned. Typically, 'origin' is set as the default remote name during cloning, but it's a convention and can be customized to any preferred name)

Here is an example of how to push commits to a remote repository, set the upstream of the branch, and use the shorthand command:

# Push local commits to the remote repository
git push <remote> <branch>

# Set the upstream of the branch
git push -u <remote> <branch>

# Push to the upstream using shorthand
git push

Git Pull

The git pull command is used to download commits and other changes from a remote repository and immediately update the local repository to match that content. It's a common task in collaborative Git-based workflows, as it allows you to synchronize your local repository with the remote one.

When you use git pull, git will try to merge the changes automatically. But if there are conflicts between the local and remote changes, it will stop the process and ask you to resolve the conflicts before proceeding with the merge.

It's considered a good practice to pull the changes from the remote repository before pushing your own changes. This way you'll avoid conflicts and ensure that your local repository is up-to-date with the remote one.

Git Fetch

The git fetch command downloads commits, files, and references from a remote repository. However, these changes are not immediately integrated into the working files. To view the downloaded content, you must explicitly switch to the specific remote branch.

Fetching provides a way to safely review commits without automatically merging them into your local repository, as opposed to the git pull command, which combines git fetch with git merge to automatically integrate changes into your local branch.

Here is an example of how to fetch commits from a remote repository and review the changes:

# Fetch commits from the remote repository
git fetch origin feature

# Check out the fetched branch
git checkout origin/feature

Merging and Rebasing branches

Merging

Merging serves as a method to combine branches and their respective histories, a common practice in Git, especially in workflows like the feature branch model. In this approach, developers create a new branch for each feature, enabling them to work on the feature independently of the main development line.

Throughout development, updates from the primary branch, often named main or master, are regularly merged into the feature branch, ensuring it stays current with the latest changes.

Upon completing the feature, the feature branch undergoes a merge back into the primary branch, integrating the changes into the main development line.

Merge commits are distinctive, having two parent commits—one from the current branch and the other from the branch being merged. Git attempts to automatically merge the separate histories during a merge commit. However, if a merge conflict arises, indicating conflicting changes in both histories, Git requires user intervention to resolve the conflict.

Rebasing

Rebasing, a specialized Git utility, enhances the integration of changes between branches, offering an alternative to merging.

The process involves moving or "replaying" a sequence of commits from one branch onto the tip of another. By updating the target branch with the latest commits from the source, it effectively "replays" these commits on top of the target branch, facilitating the incorporation of new changes while maintaining a linear history.

In the context of a feature branching workflow, git rebase is particularly valuable. It enables the integration of changes from the main branch into a feature branch, preserving a linear commit history. This choice over git merge aids in presenting a clearer development flow without generating additional merge commits.

It's essential to note that rebasing alters commit history, making it advisable to avoid if the branch has been shared or if changes have been pushed to a public branch.

Rebasing also provides the flexibility to add or drop commits before a specified commit hash. When executed in interactive mode, Git opens a text editor, displaying a list of commits within the specified range and a set of commands (pick, reword, edit, squash, and drop) for user selection.

GitHub and contributing to open source

GitHub is a platform that hosts your repositories and aids in collaboration on software projects. GitHub provides you with a safe space to store your code so that even in a worst-case scenario such as a system failure, you will always have a backup of your code base.

Pull Request

A pull request is a feature provided by GitHub (and other web-based Git hosting services), it is not a native feature of Git. A pull request enables you to notify others about changes that you have pushed to a branch in a repository and request that they merge your changes into the main branch.

Upon opening a pull request, you can include a description of the changes and the rationale behind them. Collaborators on the repository have the opportunity to review the proposed modifications, engage in discussions, and leave comments. While the pull request is active, you can continue making additional commits to the branch to address any feedback received.

Pull request is a powerful feature that allows developers to collaborate and review code changes before they are merged into the main branch. It's often used in Git-based workflows to facilitate code review, testing and quality assurance processes.

Forking

A fork is a copy of a repository that you have control over, it can be thought of as your own personal version of the original repository. Forks allow you to make changes to a project without affecting the original repository.

In most cases, open-source projects do not allow contributors to push changes directly to the original repository. Instead, contributors are expected to fork the repository, make changes to their own copy, and then submit a pull request to the maintainers of the original repository.

When you fork a repository on GitHub, it creates a copy of the repository under your own account, which you can then clone to your local machine. Once you've cloned the repository, you will need to add another remote to your local copy, this remote should point to the original repository that you cloned from. This is necessary so that you can fetch the latest commits from the original repository and keep your fork up-to-date.

You can then make changes to your local copy of the repository, commit your changes, and push them to your fork on GitHub. Once you're ready to submit your changes, you can create a pull request to request that the maintainers of the original repository review and merge your changes.

The following example demonstrates how to add a new remote named upstream that points to the original repository:

git remote add upstream https://github.com/facebook/react.git

PS - The cover image features a dog playing fetch with a branch (twig). Get it?

Resources :
https://git-scm.com/book/en/v2
https://nvie.com/posts/a-successful-git-branching-model/
https://www.atlassian.com/git/tutorials/comparing-workflows

Song of the day : Saturnus - I long

youtube.com

Understanding Keys in Relational Databases 🔑

Adhiraj Kinlekar — Sun, 12 Nov 2023 04:45:14 +0000

Keys are used to uniquely identify records or rows of data in a table or to establish and identify relationships between tables. Mainly, there are eight different keys in relational databases.

Super key : A Super key is any combination of columns that can be used to uniquely identify a row.
Candidate key : A Candidate Key is the minimal amount of columns that can be used to uniquely identify a row. All super keys can’t be candidate keys but any candidate key can be a super key.
Primary key : A Primary key is a key which uniquely identifies a row. Out of all the Candidate keys that are possible for a table, there can be only one key that can be used as a Primary Key. In other words, a Primary key is the Candidate key selected by the database administrator to uniquely identify rows in a table. A primary key cannot have null or duplicate values.
Alternate key : A candidate key which is not selected as a primary key is called an alternate or a secondary key.
Surrogate key : A surrogate key is a key which is a primary key but the column on which the key is applied is unrelated to the data present in the table. An example of a surrogate key would an auto incrementing Id column which is marked as a primary key.
Composite key : A table can have only one primary key, which may consist of single or multiple fields. When multiple fields are used as a primary key, it is called a composite key.
Foreign key : A foreign key is a column in the table that is the primary key in another table. It is useful for drawing relations between the tables.
Compound key : A compound key is similar to a composite key in that two or more fields are used to uniquely identify a row. However, a compound key is formed when a foreign key is involved in the distinctive identification.

Out of all the keys, three play a significant role in designing a well-organized and robust database system: the primary key, which uniquely identifies records; the foreign key, which establishes relationships between tables; and, while not always chosen as the primary key, candidate keys are vital because they represent the minimal set of columns that can uniquely identify a row.

Song of the day : Cynic - How could I

Understanding the four Pillars of Object-Oriented Programming using JavaScript 💊

Adhiraj Kinlekar — Sat, 11 Nov 2023 08:49:07 +0000

Object Oriented Programming

Object-Oriented Programming is a programming paradigm that enables you to model and structure your code using objects and classes. JavaScript is not a full-fledged OOP language, but you can still leverage OOP's core principles to write cleaner and more maintainable code. There are four main pillars of Object-Oriented Programming:

Abstraction

Abstraction means hiding the complex implementation details and exposing only what is necessary. Even though JavaScript lacks interfaces or abstract classes, we can still achieve abstraction through other means.

One effective approach for implementing abstraction is to expose only the necessary methods and then, through this exposed method, invoke the private methods of the class. This strategy effectively conceals the underlying complexities, which is a fundamental aspect of abstraction.

class Auth {

    constructor() {}

    #validate() {
    // Private method
    }

    #sendOnboardingEmail() {
    // Private method
    }

    // Public method that calls private methods
    signUp() {
      this.#validate();
      // Execute signUp functionality
      this.#sendOnboardingEmail();
    }
}

const auth = new Auth();

// Calls the public method, which, in turn, calls private methods
auth.signUp();

Encapsulation

When you search the internet for information about Abstraction and Encapsulation, you will likely come across numerous articles that sometimes present conflicting ideas. In my understanding, although abstraction and encapsulation are different concepts, they often complement each other. In the code block above, private accessors are utilized, enabling controlled access to the class, aligning with the principles of Encapsulation. Encapsulation promotes the idea of bundling data and the functions that operate on that data into a single, self-contained package. This encapsulated entity can control how the data is accessed, modified, or interacted with.

Even though Encapsulation is an OOP concept, it can be implemented without the use of classes and objects by utilizing Closures. A closure is a mechanism that enables an inner function to access the variables and parameters of its outer function, even after the outer function has completed its execution. Closures achieve encapsulation by packaging the actual code (the body of the function) along with the variables and parameters that the function can access during its execution. The exclusive method for accessing the encapsulated data is through the function.

function createCounter() {

  let count = 0; // This variable is encapsulated within the closure.

  function increment() {
    count++; // The inner function can access the 'count' variable.
    console.log(count)
  }

  return increment; // Return the inner function (closure).
}

const counter = createCounter();

Inheritance

When a class acquires the members and behaviors of its parent class, it is known as Inheritance. Inheritance provides code reusability and encourages modular design by breaking down a complex system into smaller, manageable components. When you need to make changes or updates to shared functionality, you can do so in the base class. These changes automatically apply to all derived classes, reducing maintenance efforts and ensuring consistency throughout your codebase.

class Person {

  constructor(name, age) {
    this.name = name;
    this.age = age;
  }

  sayHello() {
    console.log(`Hello, my name is ${this.name}, and I am ${this.age} years old.`);
  }
}

// Create a derived class Student that inherits from Person
class Student extends Person {

  constructor(name, age, studentId) {
    super(name, age); // Call the parent class constructor using super
    this.studentId = studentId;
  }

  study(subject) {
    console.log(`${this.name} with student ID ${this.studentId} is studying ${subject}.`);
  }
}

// Create instances of Person and Student
const person1 = new Person('Alice', 30);

const student1 = new Student('Bob', 25, '12345');

// Use the inherited methods
person1.sayHello();

student1.sayHello();

student1.study('Math');

Polymorphism

The term 'polymorphism' means having many forms. The concept of polymorphism enables us to perform different operations in various scenarios. In object-oriented programming languages such as C#, polymorphism is achieved through the use of interfaces and abstract classes, as well as through the use of virtual methods and overriding in inheritance. While JavaScript does not provide comprehensive support for polymorphism, we can still achieve it.

Polymorphism can be attained by using inheritance and by overriding the base class. You do not need to explicitly indicate that a method is being overridden since JavaScript uses a prototype-based inheritance model, and method overriding is accomplished simply by defining a method with the same name in a subclass. The new method in the subclass effectively replaces the method with the same name in the base class, allowing you to perform different actions in different scenarios, which aligns with the concept of polymorphism

class Transport {

  constructor() {}

  drive() {
    console.log("Driving...");
  }

  fly() {
    console.log("Flying...");
  }
}

// Create a derived class Car that inherits from Transport
class Car extends Transport {

  constructor() {
    super();
  }

// Overrides it's base implementation
  fly() {
    console.log("I am a car, I cannot fly");
  }
}

const audi = new Car();

audi.fly();

Song of the day : Agalloch - Hawthorne Passage