🚧 update some creational modal

Author: tangweikun

SOLID.md

@@ -0,0 +1,17 @@
+- Single Responsibility Principle 单一职责原则
+
+  一个类只负责一件事，也就是把关联性强的内容聚合到一个类里面，不掺杂其它的影响。
+
+- Open/Closed Principle 开放封闭原则
+
+  实体应该对扩展是开放的，对修改是封闭的。即可扩展(extension)，不可修改(modification)。
+
+- Liskov Substitution Principle 里式替换原则
+
+  一个对象在其出现的任何地方，都可以用子类实例做替换，并且不会导致程序的错误。
+
+- Interface Segregation Principle 接口分离原则
+
+  一个类不应该强制让它继承它不需要的接口，可以将接口拆分更细粒度，有助于解耦。
+
+- Dependency Inversion Principle 依赖倒置原则

creational/README.md

@@ -0,0 +1,13 @@
+## 创建型模式
+
+- 简单工厂模式(simple-factory)
+
+- 工厂方法模式(factory-method)
+
+- 抽象工厂模式(abstract-factory)
+
+- 生成器模式(builder)
+
+- 原型模式(prototype)
+
+- 单例模式(singleton)

creational/abstract-factory/README.md

@@ -1 +1,3 @@
 # Abstract Factory Pattern(抽象工厂模式)
+
+- https://refactoringguru.cn/design-patterns/abstract-factory

creational/abstract-factory/Sample-1.ts

@@ -0,0 +1,146 @@
+/**
+ * The Abstract Factory interface declares a set of methods that return
+ * different abstract products. These products are called a family and are
+ * related by a high-level theme or concept. Products of one family are usually
+ * able to collaborate among themselves. A family of products may have several
+ * variants, but the products of one variant are incompatible with products of
+ * another.
+ */
+interface AbstractFactory {
+  createProductA(): AbstractProductA;
+
+  createProductB(): AbstractProductB;
+}
+
+/**
+ * Concrete Factories produce a family of products that belong to a single
+ * variant. The factory guarantees that resulting products are compatible. Note
+ * that signatures of the Concrete Factory's methods return an abstract product,
+ * while inside the method a concrete product is instantiated.
+ */
+class ConcreteFactory1 implements AbstractFactory {
+  public createProductA(): AbstractProductA {
+    return new ConcreteProductA1();
+  }
+
+  public createProductB(): AbstractProductB {
+    return new ConcreteProductB1();
+  }
+}
+
+/**
+ * Each Concrete Factory has a corresponding product variant.
+ */
+class ConcreteFactory2 implements AbstractFactory {
+  public createProductA(): AbstractProductA {
+    return new ConcreteProductA2();
+  }
+
+  public createProductB(): AbstractProductB {
+    return new ConcreteProductB2();
+  }
+}
+
+/**
+ * Each distinct product of a product family should have a base interface. All
+ * variants of the product must implement this interface.
+ */
+interface AbstractProductA {
+  usefulFunctionA(): string;
+}
+
+/**
+ * These Concrete Products are created by corresponding Concrete Factories.
+ */
+class ConcreteProductA1 implements AbstractProductA {
+  public usefulFunctionA(): string {
+    return 'The result of the product A1.';
+  }
+}
+
+class ConcreteProductA2 implements AbstractProductA {
+  public usefulFunctionA(): string {
+    return 'The result of the product A2.';
+  }
+}
+
+/**
+ * Here's the the base interface of another product. All products can interact
+ * with each other, but proper interaction is possible only between products of
+ * the same concrete variant.
+ */
+interface AbstractProductB {
+  /**
+   * Product B is able to do its own thing...
+   */
+  usefulFunctionB(): string;
+
+  /**
+   * ...but it also can collaborate with the ProductA.
+   *
+   * The Abstract Factory makes sure that all products it creates are of the
+   * same variant and thus, compatible.
+   */
+  anotherUsefulFunctionB(collaborator: AbstractProductA): string;
+}
+
+/**
+ * These Concrete Products are created by corresponding Concrete Factories.
+ */
+class ConcreteProductB1 implements AbstractProductB {
+  public usefulFunctionB(): string {
+    return 'The result of the product B1.';
+  }
+
+  /**
+   * The variant, Product B1, is only able to work correctly with the variant,
+   * Product A1. Nevertheless, it accepts any instance of AbstractProductA as
+   * an argument.
+   */
+  public anotherUsefulFunctionB(collaborator: AbstractProductA): string {
+    const result = collaborator.usefulFunctionA();
+    return `The result of the B1 collaborating with the (${result})`;
+  }
+}
+
+class ConcreteProductB2 implements AbstractProductB {
+  public usefulFunctionB(): string {
+    return 'The result of the product B2.';
+  }
+
+  /**
+   * The variant, Product B2, is only able to work correctly with the variant,
+   * Product A2. Nevertheless, it accepts any instance of AbstractProductA as
+   * an argument.
+   */
+  public anotherUsefulFunctionB(collaborator: AbstractProductA): string {
+    const result = collaborator.usefulFunctionA();
+    return `The result of the B2 collaborating with the (${result})`;
+  }
+}
+
+/**
+ * The client code works with factories and products only through abstract
+ * types: AbstractFactory and AbstractProduct. This lets you pass any factory or
+ * product subclass to the client code without breaking it.
+ */
+function clientCode(factory: AbstractFactory) {
+  const productA = factory.createProductA();
+  const productB = factory.createProductB();
+
+  console.log(productB.usefulFunctionB());
+  console.log(productB.anotherUsefulFunctionB(productA));
+}
+
+/**
+ * The client code can work with any concrete factory class.
+ */
+console.log('Client: Testing client code with the first factory type...');
+clientCode(new ConcreteFactory1());
+
+console.log('');
+
+console.log(
+  'Client: Testing the same client code with the second factory type...'
+);
+clientCode(new ConcreteFactory2());

creational/builder/Sample-5.ts

@@ -0,0 +1,141 @@
+/**
+ * The Builder interface specifies methods for creating the different parts of
+ * the Product objects.
+ */
+interface Builder {
+  producePartA(): void;
+  producePartB(): void;
+  producePartC(): void;
+}
+
+/**
+ * The Concrete Builder classes follow the Builder interface and provide
+ * specific implementations of the building steps. Your program may have several
+ * variations of Builders, implemented differently.
+ */
+class ConcreteBuilder1 implements Builder {
+  private product: Product1;
+
+  /**
+   * A fresh builder instance should contain a blank product object, which is
+   * used in further assembly.
+   */
+  constructor() {
+    this.reset();
+  }
+
+  public reset(): void {
+    this.product = new Product1();
+  }
+
+  /**
+   * All production steps work with the same product instance.
+   */
+  public producePartA(): void {
+    this.product.parts.push('PartA1');
+  }
+
+  public producePartB(): void {
+    this.product.parts.push('PartB1');
+  }
+
+  public producePartC(): void {
+    this.product.parts.push('PartC1');
+  }
+
+  /**
+   * Concrete Builders are supposed to provide their own methods for
+   * retrieving results. That's because various types of builders may create
+   * entirely different products that don't follow the same interface.
+   * Therefore, such methods cannot be declared in the base Builder interface
+   * (at least in a statically typed programming language).
+   *
+   * Usually, after returning the end result to the client, a builder instance
+   * is expected to be ready to start producing another product. That's why
+   * it's a usual practice to call the reset method at the end of the
+   * `getProduct` method body. However, this behavior is not mandatory, and
+   * you can make your builders wait for an explicit reset call from the
+   * client code before disposing of the previous result.
+   */
+  public getProduct(): Product1 {
+    const result = this.product;
+    this.reset();
+    return result;
+  }
+}
+
+/**
+ * It makes sense to use the Builder pattern only when your products are quite
+ * complex and require extensive configuration.
+ *
+ * Unlike in other creational patterns, different concrete builders can produce
+ * unrelated products. In other words, results of various builders may not
+ * always follow the same interface.
+ */
+class Product1 {
+  public parts: string[] = [];
+
+  public listParts(): void {
+    console.log(`Product parts: ${this.parts.join(', ')}\n`);
+  }
+}
+
+/**
+ * The Director is only responsible for executing the building steps in a
+ * particular sequence. It is helpful when producing products according to a
+ * specific order or configuration. Strictly speaking, the Director class is
+ * optional, since the client can control builders directly.
+ */
+class Director {
+  private builder: Builder;
+
+  /**
+   * The Director works with any builder instance that the client code passes
+   * to it. This way, the client code may alter the final type of the newly
+   * assembled product.
+   */
+  public setBuilder(builder: Builder): void {
+    this.builder = builder;
+  }
+
+  /**
+   * The Director can construct several product variations using the same
+   * building steps.
+   */
+  public buildMinimalViableProduct(): void {
+    this.builder.producePartA();
+  }
+
+  public buildFullFeaturedProduct(): void {
+    this.builder.producePartA();
+    this.builder.producePartB();
+    this.builder.producePartC();
+  }
+}
+
+/**
+ * The client code creates a builder object, passes it to the director and then
+ * initiates the construction process. The end result is retrieved from the
+ * builder object.
+ */
+function clientCode(director: Director) {
+  const builder = new ConcreteBuilder1();
+  director.setBuilder(builder);
+
+  console.log('Standard basic product:');
+  director.buildMinimalViableProduct();
+  builder.getProduct().listParts();
+
+  console.log('Standard full featured product:');
+  director.buildFullFeaturedProduct();
+  builder.getProduct().listParts();
+
+  // Remember, the Builder pattern can be used without a Director class.
+  console.log('Custom product:');
+  builder.producePartA();
+  builder.producePartC();
+  builder.getProduct().listParts();
+}
+
+const director = new Director();
+clientCode(director);

creational/factory-method/README.md

@@ -1 +1,3 @@
 # Factory Method Pattern(工厂方法模式)
+
+- https://refactoringguru.cn/design-patterns/factory-method