[Design Pattern] Factory Pattern

팩토리패턴

객체를 생성하는 부분을 떼어내서 추상화한 패턴이다. 객체를 생성하는 로직을 클라이언트로부터 숨겨서 클라이언트의 코드를 깔끔하게 유지할 수 있다. 객체 생성을 담당하는 별도의 Fatory 객체를 만들어서 어떤 객체를 생성할 지에 대한 정보만 넘겨주면 된다.

뼈대를 구성하는 상위 클래스와 객체 생성에 관한 구체적인 내용을 담은 하위클래스로 분리한다. 이렇게 되면 상위클래스는 어떤 객체를 생성할 지에 대한 구체적인 정보 알 필요가 없기 때문에 하위 클래스간 결합이 느슨해진다.

추후에 리팩터링을 진행할 때에도 한 곳만 수정하면 되기 때문에 유지 보수하기가 용이하다. 보통 객체를 생성할 때 의존성이 너무 많거나, 조건에 따라 서로 다른 객체를 생성할 때 사용한다.

구현

class NITORI {
  constructor () {
    this.name = "NITORI"
  }
}

class MUJI {
  constructor() {
    this.name = " MUJI"
  }
}

class MUJIfactory {
  static createNewBranch() {
    return new MUJI()
  }
}
class NITORIfactory {
  static createNewBranch() {
    return new NITORI()
  }
}

const factoryList = {
    MUJI : MUJIfactory,
    NITORI : NITORIfactory
};

class StartUpFactory {
  static createStartUp (type) {
    const industry = factoryList[type];
    return industry.createNewBranch()
  }
}

const main = () => {
  const SPA = StartUpFactory.createStartUp("MUJI")
  console.log(SPA)
}

main()

StartUpFactory 라는 클래스에서 뼈대만 남겨두고, MUJI , NITORI인지 타입에 따라 객체를 생성하는 각각의 MUJIfactory ,NITORIfactory를 호출하도록 한다. 각각의 factory에서 생성한 인스턴스를 StartUpFactory에 주입하고 있기 때문에 의존성 주입이라고 볼 수 있다.

추후에 IKEA같은 브랜드가 추가될 때, StartUpFactory 수정없이 클래스와 팩토리만 정의면 객체 생성이 가능하므로 확장성이 좋다.

싱글톤 패턴의 문제 해결

싱글톤 패턴에서 문제가 되는 것은 TDD시 독립적인 테스트 환경을 만들기 어렵다는 이유 때문이었다. 팩토리 패턴에서는 테스트를 진행할 때 가짜 팩토리를 생성하고 주입하기가 훨씬 용이하다.

class MUJI {
  constructor() {
    this.name = " MUJI"
  }
}

class mockMUJI {
  constructor() {
    this.name = "mockMUJI"
  }
}

class MockMUJIfactory {
  static createNewBranch() {
    return new mockMUJI()
  }
}

class MUJIfactory {
  static createNewBranch() {
    return new MUJI()
  }
}

class StartUpFactory {
  static createStartUp (type) {
    const industry = factoryList[type];
    return industry.createNewBranch()
  }
}

const test = (factory) => {
    const services = factory.createNewBranch();
    console.log(`현재 실행중인 factory는 ${factory.createNewBranch().name}`)
};

test(MockMUJIfactory);
test(MUJIfactory);