I have been a Front-end engineer since 2021. I love this job, but...

✅ When a product manager defines a feature, I can finish the requirement
✅ When I notice the performance should and can be optimized, I know how to do it
✅ When a bug happens, I can trace and resolve it

TL;DR: Developed and maintained the web platform in my resume

Gradually, I noticed that I always focus on how I can "finish" a feature, instead of how I can "design" a feature. And this is what I need, a thinking of software design.

So, I would like to share what I learn from design pattern and hope to receive some feedbacks from everyone.

=======================================================

Why do we need design pattern?

Each pattern describes a problem that occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice. —— Christopher Alexander

SOLID principles

There are five principles to describe software design, but I am not gonna to discuss the SOLID principles at first. Instead, Let's firstly talk about the core concept of design pattern, Encapsulating what varies.

ECV (Encapsulating what varies)

The level of complexity of software design increases gradually, so we need pattern to help us understand the whole structure. What we can do is to minimize the impact of frequently changing code and to ensure the frequently changing code is flexible and infrequently changing code is stable.

Factory Pattern

What does a factory do? If you have visited a factory, no matter for cloth, shoes, or phones, it manufactures products by following a pattern, so the product can be the same quality.

Let's image you would like to create a user data

const userA = {
  name: "Alex",
  age: 28
  career: programmer
}

But, one day, your colleague ask you to create his/her data. So, you have to do it again

const userA = {
  name: "Alex",
  age: 28
  career: programmer
}

const userB = {
  name: "Ben",
  age: 30
  career: administrator
}

You notice that what if everyone asks you to create a user data, it's totally a mess...So, we can create a constructor to create user data. So, you do not need to create a user data manually next time.

class User {
  constructor(name, age, career) {
    this.name = name
    this.age = age
    this.career = career
  }
}

const userC = new User("Cat", 30, "engineer")

In this example, which part is changeable and which is not changeable?

It is clear that the value of user's name, age, and career is changeable and user's features is not changeable. Every user has these three features.

So, what a constructor does is to encapsulating the process of value assignment to make sure that each user has the common features. On the other hand, we make the value of these three features flexible.

If we would like to define users' work by their career, we can do like below

class User {
  constructor(name, age, career, job) {
    this.name = name
    this.age = age
    this.career = career
    this.job = job
  }
}

function Factory(name, age, career) {
  let job
  switch(career) {
    case  "programmer":
     job = ['xxx', 'yyy', 'zzz']
    break;
    case  "accounting":
     job = ['abc', 'def', 'jkm']
    break;
    ...
  }
  return new User(name, age, career, job)
}

So, if I want to create a programmer's user data, I can do

const userE = Factory("Mary", 30, "programmer")
console.log(userE)// {"Mary", age: 30, career: "programmer", job: ['xxx', 'yyy', 'zzz']}

Summary

If you are using tons of new to create an object instance, you may think if using the factory pattern to simply and refactor the code.

To be continued...