Forem: Yair Mishnayot

SOLID Programming Principles Explained(Part 1)

Yair Mishnayot — Wed, 08 Feb 2023 08:37:37 +0000

As software systems grow in size and complexity, they can become increasingly difficult to maintain and scale. This is often due to poor design decisions that make the system rigid, fragile, and hard to change. This can lead to a phenomenon known as “code rot,” where the codebase becomes so difficult to work with that developers are afraid to make changes, resulting in an outdated system.

The SOLID principles are a set of guidelines that aim to solve the said problems, and those principles are:

Single Responsibility Principle (SRP): “A class should have one and only one reason to change”.
Open-Closed Principle (OCP): “Objects should be open for extension but closed for modification”.
Liskov Substitution Principle (LSP): “Subtypes should be substitutable for their base types”.
Interface Segregation Principle (ISP): “A client should not be forced to implement interfaces it does not use”.
Dependency Inversion Principle (DIP): “High-level modules should not depend on low-level modules, but rather both should depend on abstractions”.

In this article, we will dive deep into the first principle and cover the rest of the principles in the next articles.

The Single Responsibility Principle

Let's think of a car: A car has many parts, such as the engine, transmission, wheels, and brakes. Each of these parts has a specific function and is responsible for one task. The engine is responsible for providing power to the car, the transmission is responsible for shifting gears, the wheels are responsible for propelling the car, and the brakes are responsible for slowing the car down. Each part is built and designed to perform one specific task and they work together to make the car move. In the same way, each class or module in software development should have one, and only one, responsibility and they work together to make the software work.

Now, let's think about what will happen if we will combine multiple parts of the car into one component. For example, instead of having separate parts for the engine, transmission, and brakes, we would have one part that is responsible for all three functions. This would make the component much more complex and harder to maintain. Imagine trying to fix or replace just the brakes while the engine is connected to it and all the other functions, it would be difficult and time-consuming.

Similarly, in software development, if we do not follow the single responsibility principle, we end up with classes or modules that have multiple responsibilities. This makes the code harder to understand, harder to test, and harder to maintain. When a change is needed, it becomes difficult to determine which part of the code needs to be modified and what impact that change will have on the rest of the system. In addition, it can increase the risk of bugs and make it harder to identify where the issue is coming from.

And that is the idea behind this principle: “A class should have one and only one reason to change”.

So, how can we implement this principle?

Implementation

Let's start with a simple example. Consider a class Invoice that has the responsibilities of managing an invoice's details, calculating the total amount, and printing the invoice:

class Invoice {
  constructor(items) {
    this.items = items;
  }

  addItem(item) {
    this.items.push(item);
  }

  calculateTotal() {
    let total = 0;
    for (const item of this.items) {
      total += item.price * item.quantity;
    }
    return total;
  }

  printInvoice() {
    console.log("Invoice Details:");
    for (const item of this.items) {
      console.log(`- ${item.name}: $${item.price} x ${item.quantity}`);
    }
    console.log(`Total: $${this.calculateTotal()}`);
  }
}

This class violates the Single Responsibility Principle as it has three responsibilities: managing the invoice’s details, calculating the total amount, and printing the invoice.

We can refactor this class to follow the Single Responsibility Principle by separating these three responsibilities into three different classes: Invoice, InvoiceCalculator, and InvoicePrinter:

class Invoice {
  constructor(items) {
    this.items = items;
  }

  addItem(item) {
    this.items.push(item);
  }
}

class InvoiceCalculator {
  constructor(items) {
    this.items = items;
  }

  calculateTotal() {
    let total = 0;
    for (const item of this.items) {
      total += item.price * item.quantity;
    }
    return total;
  }
}

class InvoicePrinter {
  constructor(items) {
    this.items = items;
  }

  printInvoice() {
    console.log("Invoice Details:");
    for (const item of this.items) {
      console.log(`- ${item.name}: $${item.price} x ${item.quantity}`);
    }
    console.log(`Total: $${this.calculateTotal()}`);
  }
}

In this refactored code, the Invoice class is now only responsible for managing the invoice's details, the InvoiceCalculator class is only responsible for calculating the total amount, and the InvoicePrinter class is only responsible for printing the invoice. This makes the code easier to understand, maintain, and test, and also makes it easier to make changes to one responsibility without affecting the other two responsibilities.

To use these classes, we can create instances of each class and pass the necessary information between them, like so:

const invoice = new Invoice([
  { name: "Item 1", price: 10, quantity: 2 },
  { name: "Item 2", price: 20, quantity: 1 },
]);

const invoiceCalculator = new InvoiceCalculator(invoice.items);
const invoicePrinter = new InvoicePrinter(invoice.items);

invoice.addItem({ name: "Item 3", price: 5, quantity: 3 });

const total = invoiceCalculator.calculateTotal();
invoicePrinter.printInvoice();

Let’s look at another example. We have a web application that is responsible for saving user’s data into DB:

class UserController {
    constructor() {}

    async createUser(request, response) {
        const user = request.body;
        const validationErrors = this.validateUser(user);

        if (validationErrors.length) {
            return response.status(400).send({ errors: validationErrors });
        }

        const newUser = await this.saveUserToDB(user);

        return response.status(200).send({ user: newUser });
    }

    validateUser(user) {
        const errors = [];

        if (!user.email) {
            errors.push({ field: 'email', message: 'Email is required' });
        }

        if (!user.password) {
            errors.push({ field: 'password', message: 'Password is required' });
        }

        return errors;
    }

    async saveUserToDB(user) {
        // code to save user to database
    }
}

This example violates the Single Responsibility Principle because the controller class should have only one goal: handling the communication between the client and the business logic, but instead it has three responsibilities:
validating user data, saving the user to the database, and handling the communication between the client and the business logic.

To make this code follow the SRP principle, we can refactor it as follows:

class UserController {
    constructor(userRepository, validator) {
        this.userRepository = userRepository;
        this.validator = validator;        
    }

    createUser(user) {
        if (!this.validator.isValid(user)) {
            throw new Error('User is not valid');
        }

        this.userRepository.save(user);
    }
}

class UserRepository {
    save(user) {
        // Save the user to the database
    }
}

class Validator {
    isValid(user) {
        // Validate the user object
        return true;
    }
}

Now, the UserControllerclass is responsible only for coordinating the process of creating a user, and delegating tasks to its collaborators such as userRepository, and validator. The actual work of saving the user and validating the user is done by separate classes. This makes the code easier to maintain and test, as each class has a single responsibility and can be tested in isolation.

The Hard Part

We get a lot of benefits from implementing the SRP. with that being said, for me, the hardest part of this principle is the trade-off between complexity and maintainability: Balancing the trade-off between the increased complexity(more and more files) and improved maintainability of the codebase(responsibilities are separated into those different files) is a challenge when applying the SRP.

Implementation Tip

It can be hard sometimes to implement this principle. I thought about that a lot, and I realized that when I ask the next question I usually end up implementing this principle successfully:

Does my class name indicate what it does? and does its methods indicate how it does it?

From my perspective, the class name should indicate its ultimate goal, and its methods should indicate how it achieves that ultimate goal. The question above helped me in a lot of cases when I wanted to implement SRP.

Conclusion

So that is the Single Responsibility principle, I hope this article helped you. In the next one, I will cover the Open-Closed Principle.

CSS Directional Properties vs Logical Properties

Yair Mishnayot — Sun, 21 Aug 2022 06:38:03 +0000

For a lot of people, responsive web design means "make this website look good regardless of the device it's being displayed on". It's true, but responsiveness means much more than just the fact that our content can fit to the user's screen size.

One subject to keep in mind is Internalization. Let's take a look at that definition from w3.org :

"If you internationalize, you design or develop your content, application, specification, and so on, in a way that ensures it will work well for, or can be easily adapted for, users from any culture, region, or language."
source: Internationalization - W3C

So, when we want to internationalize a web app, besides translations, we also need to ask: "what will happen in the day that the direction of the text will be the opposite of the current direction?"

You might develop your web app for the LTR languages, but then the business decides to enter a market which it's language direction is RTL. In those cases, it's really important to know the difference between CSS Directional Properties, and CSS Logical Properties.

CSS Directional Properties

As the name suggests - CSS Directional properties are based on direction. We all use them daily: top, right, bottom, left. If we want our div to have a margin on its right side, we will use margin-right, and yay, problem solved.

The problem with that approach is that if we change the direction of the page, let's say from LTR to RTL, the page direction changes from one side to the other, but the margin on the div did not move to the other side.

CSS Logical Properties

In simple terms, logical properties are properties that are linked to the flow of text, or the document, and not to a static direction. We don't use top, bottom, left, and right, but instead - we use more fluent terms, like start and end, which allows us to have more flexibility with our layouts.

Let's look at an example:

// HMTL
<body>
  <div class="content">
    <h1>This is the title</h1>
    <p>This is the content</p>
  </div>
</body>
// CSS
body{
  direction: ltr;
}
.content{
  border: 1px solid black;
  width: 400px;
}
h1, p{
  margin-left: 1.5rem;
}

Now let's see how we do the same thing with logical properties.

h1, p{
  margin-inline-start: 1.5rem;
}

The difference is that now our content will know to have margin from the start of the natural direction flow of the page, and not statically choose left or right.

You can see this difference in the next pen. Check what happens when you change the direction of the body from ltr to rtl(click on edit in the top-right corner):

The next steps

Moving to CSS logical properties can be a bit tricky for those who are used to directional properties. For all of you that want to dig deeper into this subject, I would suggest checking out the MDN guide about CSS logical properties

Let’s Learn Git Reset With Practical Example

Yair Mishnayot — Wed, 01 Jun 2022 06:08:43 +0000

Through our workflow with git as developers, we occasionally need to undo changes that we did to our code, and that is when we want to use git reset.

But, if I’m being honest, sometimes that can be confusing, and even scary, to use git reset. I used to find this command as a “black box” that I don’t know exactly what it does, but I do know that I’m scared that I might delete somehow parts of my code that I want to keep, or even somehow destroy the entire project.

In this post, we will take a look at git in general, and specifically git reset, to understand it. Because, like a lot of things in our life, we are afraid of what we don’t understand.

Note: This post was written assuming you have at least a basic familiarity with git and know basic commands of it.

How git works

We can think about git as a content manager that manages three trees:
1. The Head: points to our last commit.
2. The index: points to our next commit. After we use the “git add” command, the files we performed that command on are going to the staging area.
3. The working Directory(Working Tree): The place we work on our actual files in the project, before adding them to our stating area.

Note: The Head and the Index store their files inside the .git directory.

Basic Lifecycle

Usually, after adding a new file to our repository, we will have the following cycle:

Make changes to our file.
Stage our file.
Commit our file.
Push our file to our remote repository.

Step 1 is happening in the working tree. We made changes but did not stage those yet.

Step 2 is happening in the index tree. We staged the changes that we did, but we did not commit those yet.

step 3 is happening in the head tree. From there, we push those changes to our remote repository.

Using git reset

Now that we understand git better, we can continue to the git reset command. There are two parts to git reset:

1. The commit we go back to.
2. In which trees we want to keep our changes.

To get there, we get three “flags” for the git reset command:

Soft: remove the changes from the head tree, and keep them in the index and the working directory trees.
Mixed: remove the changes from the head and the index trees, and keep them in the working directory tree.
Hard: remove the changes from all three trees.

So let’s look at an example. We have an initialized git repo, we created one file in the repo named file1.txt. When we run git status we get:

git status
On branch master
No commits yet
Untracked files:
(use “git add <file>…” to include in what will be committed)
file1.txt
nothing added to commit but untracked files present (use “git add” to track)

Right now our file exists only in the working directory, but not in the index. It is “untracked”. Let’s add it to our index, and rerun git status:

git commit -m “our first file”
[master (root-commit) 7ed5dc0] our first file
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 file1.txt
git status
On branch master
nothing to commit, working tree clean

As we can see after the last git status, there is nothing to commit. At this stage, all three trees are synced.

Now, let’s add another file to our directory named file2.txt, and we will go through the entire cycle again:

git status
On branch master
Untracked files:
(use “git add <file>…” to include in what will be committed)
file2.txt
nothing added to commit but untracked files present (use “git add” to track)

git add file2.txt

git status
On branch master
Changes to be committed:
(use "git restore --staged <file>..." to unstage)
new file:   file2.txt

git commit -m "added file 2"
[master 742c271] added file 2
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 file2.txt

git status
On branch master
nothing to commit, working tree clean

We can see our two commits with git log:

git log
commit 742c2713887c8b0056bea68d32f542807dca2324 (HEAD -> master)
Author: Yair <yair543210@gmail.com>
Date: Wed May 25 22:39:34 2022 +0300
added file 2
commit 7ed5dc012974aa577184f71077d02ccc63653225
Author: Yair <yair543210@gmail.com>
Date: Wed May 25 22:34:23 2022 +0300
our first file

Now let’s use git reset to go back to our first commit using the commit id. At first, we will try it without any flag:

git reset 7ed5dc012974aa577184f71077d02ccc63653225 // this is the first commit id

Now let’s rerun git status:

git status
On branch master
Untracked files:
(use “git add <file>…” to include in what will be committed)
file2.txt

When we ran git reset without any flag git used the mixed flag by default. Meaning the changes from our second commit were removed from the Head and the Index, but still stayed in the working directory. Let’s stage the changes again and commit them:

git add file2.txt
git commit -m “added file 2 again”
[master c211158] added file 2 again
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 file2.txt

Ok. now when we run git log we will see only two commits, the first commit, and the second commit:

git log
commit c211158cee7a04c1cba4c7e10a2474c64b298d1c (HEAD -> master)
Author: Yair <yair543210@gmail.com>
Date: Wed May 25 23:42:56 2022 +0300
added file 2 again // this is the new commit
commit 7ed5dc012974aa577184f71077d02ccc63653225
Author: Yair <yair543210@gmail.com>
Date: Wed May 25 22:34:23 2022 +0300
our first file

Now we will use git reset, but this time with the hard flag:

git reset — hard 7ed5dc012974aa577184f71077d02ccc63653225
HEAD is now at 7ed5dc0 our first file
git status
On branch master
nothing to commit, working tree clean

When using the “hard” flag we deleted everything that was done after the commit we went back to. Because we created another file after that commit, that file is gone:

ls
file1.txt

There is no file2.txt anymore.

Conclusion

Using git reset can be beneficial when we understand what it does. I highly recommend reading more about it and trying to use it in a safe environment like I just did in this tutorial. I truly believe that this is the best way to learn, by taking little examples.

This article was originally published at Medium

Do these 3 things when adding a new member to your team

Yair Mishnayot — Fri, 25 Feb 2022 11:35:01 +0000

As your product gets bigger so does your team. And when you want to add a new member to the team it can be challenging.

On one hand, you want them to get the handle of things as fast as you can, and fit in well with the other team members, but on the other hand, it’s hard since the product is always getting bigger and more complex, and even if you tell the new team member to ask as many questions as they can, sometimes they don’t even know what to ask.

I thought about that a lot recently, and I truly believe that if you do these 3 things, then adding a new team member will become easier.

1. Let them know that you are there in an active way:

Everyone wants to know that they matter, and for a new member it means the world if another member just comes and asks if they need anything, or if there is anything that they don’t understand and need an explanation about. Remember, even if you tell someone to ask questions, they don’t always feel comfortable to keep asking again and again and again.

Let them know you are there, help them to ask questions.

But beyond that, let them know they matter in the small things. Are they vegetarian? Is there any food that they are allergic to? You don’t know the impact of those kinds of questions, that shows you care.

Let them know they matter, and they will be motivated to fit in as fast as possible.

2. Make sure they can technically start work as fast as possible:

The way I see it, if your new member’s environment cannot be all set up and ready in 5 hours, something is not right, and you might want to think about the environment setup process.

I’m talking about computers, screen(s), users of their own, the software they need to work with, permissions on the computer(No, It is not fun to call IT every time I need something), groups they need to be in(Whatsapp, Teams, Slack, Discord, etc).

And for all the programmers, make sure that your product has proper database seeders. No one needs to get to a situation where after they clone the project to their computer and run the seeders, they don’t have enough data in the system to start with.

3. create a user guide and technical documentation

Documentations are important. They give us order, a place to go to understand things and to see them from the perspective of those who created them.

Technical documentations help the developer understand how does the project is built, and give a technical overview of the project from the basics to the more advanced parts: folder structure, style guides, design patterns, etc.

The technical documentation is supposed to help you understand how does the system is working today, and how do the different parts are connected.

The user guide is really important as well. It is supposed to give me the point of view of the user itself. What are the different areas that the user can use? how does he use it? what is the purpose of each part?

It is important to do that because it can help you as a developer to see what the user is seeing, and not what you as a developer see. It also makes it easier to simulate different scenarios better and quicker.

For example, A new developer was given a task to solve a bug that after he sent 3 reports, and then goes to the dashboard, and click on the download reports button, and instead of downloading all 3 reports it downloads 1

The first step in simulating this situation is to send 3 reports, and for that to happen you need to create 3 reports, and then find the place where you send them, and to know all of that you need some kind of reference which explains how things work, a.k.a user guide.

So these are 3 things that I think can help make the process of adding new members to the team much easier.

I would love to hear your thoughts about this subject, and what do you think can make this process easier.

How to learn things fast without going crazy

Yair Mishnayot — Thu, 06 Jan 2022 21:12:54 +0000

As people who work in the tech industry, we often need to learn new technologies for our work.
With time I found myself struggling with the same points over and over again:

1.The Tutorial Hell - with the amount of information out there it's easy to get lost very quickly. Another tutorial and then another one. At some point I have found myself just watching tutorials, instead of actually building my own things.

2.Long Form Of Content - long courses are great, really, I appreciate the time people put into those courses. The problem for me with a 12-40 hours course is that it's too much to invest in the tutorial stage, when in reality you want to start building your own things as fast as you can, because the best way of learning is by doing.

The Solution

The solution that I am about to propose is around one core idea: Learn the general idea fast, and then gradually deep dive in. From that perspective I built myself the next steps:

1. The Crash Course - I usually go to youtube, search for the subject that I'm trying to learn and add 'Crash Course' right after and pick one of the results. With time you might see that you already recognize the youtuber that created the crash course. You might also not see the term 'Crash Course' in the title of the video, but you can see that the video is short enough to be like a crash course.

Crash courses are great because they give us the big picture of what we are trying to learn, but they don't take very long to finish.

My personal rule of thumb is to pick a crash course that does not take more than 5 hours to finish. Most of them are much shorter than that.

2. The Personal Project - The idea is very straightforward: you learn by doing. The goal is to build the must simple project that concludes the ideas learnt in step 1. In this stage, all you need to care about is to see how you can build something alone based on what you saw.

It is important to build a different project than what you saw on step 1, even if the difference is small, it's still better than the same project. When you build something different it's actually make you think about the materials you learned, and not just copy-past it from the video.

It is important to say that you don't need to re-invent the wheel here. For example: if you lean Vue.js and decided for a project to build a todo-list(shocking), and now you want to learn react, it's okay to just build another todo list.

The goal here is not to get super creative with project ideas(which can be very fun though), but it's applying the new concepts and ideas we learned. Remember: you can build the exact same project, but with different technology.

3.The Deep Dive - ok, so now you have the general understanding of the technology. Now it's time to level up, and basically try to know everything you can about that technology. For me it means get to know the entire power of the technology beyond the basic use of it, and if possible, how does it work under the hood.

The first thing that I would do is go through the documentation. There are multiple benefits to this: The documentation contains the most updated information about the given technology, subjects that are not covered in other places, and how the creator of the given technology is thinking.

After that you can go in any direction you want. That is also the time to bring the 'Heavy Guns' like those 40-hrs long courses, or build big and complicated projects which use this technology.

So this is my personal two cents on learning new technologies. I would love to know your thoughts about this subject, and your own approach to learning new things.