DEV Community: Oscar

Design pattern(II) - Factory pattern

Oscar — Thu, 02 Jun 2022 05:32:42 +0000

In the previous post, I share the very basic concept of why we need the design pattern and the fundamental of the factory pattern.

We use the factory pattern to create objects that have same features, the example in the previous post

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

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)
}

There is an obvious defect. If there are hundreds of career's type and some of them are C-class (CEO, CTO, CXO), so they have very different job and permission. Factory would become too huge and complex to maintain.

You may think how we can create different users easier? Maybe we need a blueprint and use it to create an abstract factory. So, every real user is made from the abstract factory...

YES! That is today's main course, abstraction.

We know every employee has their name, age, career...and they have their permission to access a company's system. A employee can see own information. A human resource staff can see all employee's attendance records and A general manager may have more and more permission.

**But, even there are so much different type of employees, they are the user of the system.

So, in our abstract factory (UserFactory)

class UserFactory {
  constructor(name, age, career) {
    this.name = name
    this.age = age
    this.career = career
  }
  getPermission() {
    console.log("I am abstract factory")
  }
}

We are not going to use UserFactory, instead we use it to create concrete factories and we can specify a user that having a specific permission

class Programmer extends UserFactory {
  constructor(name, age, career) {
    super(name, age, career)
  }
  getPermission() {
    return new labPermission()
  }
}

class Permission {
  checkIdentity() {
    console.log("I am abstract product")
  }
}

class labPermission extends Permission {
  checkIdentity() {
    console.log("Identity checked, programmer")
  }
}

So, if a programmer wants to access to the lab, he/she can do

const programmerOne = new Programmer()
//create programmer instance

const programmerPermission = programmerOne.getPermission()

programmerPermission.checkIdentity()
//Identity checked, programmer

So, one day, if new accountant would like to create user's permission, only we need to do is to extend the class from the UserFactory. We do not revise it and not to worry about the problem mentioned above (Factory becomes too huge and complex to maintain.)

Summary

No matter the abstract factory or factory method, they are trying to decouple the invariable and variable part of a system.

There are four key elements in abstraction factory

Abstract factory: It is a blueprint and used to defined what an object looks like, UserFactory in our case.
Concrete factory: It inherits methods and features from the abstract factory. We use it to create a real object, Programmer in our case.
Abstract product: In our case, the abstract product is our Permission because we use it to create a real permission. And it is same to the abstract factory, we do not use it to new or create a real object.
Concrete product: Like labPermission. It is a real permission for programmer.

Thank you for your time. If you have any feedbacks, welcome to comment below.

Design pattern (I)

Oscar — Tue, 31 May 2022 15:37:46 +0000

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...

Test

Oscar — Mon, 22 Feb 2021 06:24:03 +0000

test