设计模式（一）工厂模式

1.前言：

1. 工厂模式属于创建型模式：

创建型模式:
这些设计模式提供了一种在创建对象的同时隐藏创建逻辑的方式，而不是使用 new 运算符直接实例化对象。
这使得程序在判断针对某个给定实例需要创建哪些对象时更加灵活。

2. 使用场景：
   当我们明确的计划在不同环境实例化不同实例时，比如：我们想把不同级别的日志记录在不同的文件中时。

3. 优点：

   • 实例化对象时只需要知道名字即可（业务和实现解耦），用户不需要关心具体实现只需要关心产品的接口即可。
   • 扩展性高，如果想增加一个产品只需要增加一个工厂类就可以了。

4.缺点：

• 工厂类会随着业务增加增加，增加了系统复杂度。
• 增加了系统具体类的依赖，这不是个好事。（这个没搞懂……哪位看知道请给我留言）

5.使用场景：

• 日志记录器：记录可能记录到本地硬盘、系统事件、远程服务器等，用户可以选择记录日志到什么地方。
• 数据库访问，当用户不知道最后系统采用哪一类数据库，以及数据库可能有变化时。
• 设计一个连接服务器的框架，需要三个协议，“POP3”、“IMAP”、“HTTP”，可以把这三个作为产品类，共同实现一个接口。

2.模式例子

//人类接口
interface Person {
    speak: () => string
}

//男人
class Man implements Person {
    speak():string {
        return "man";
    }
}

//女人
class Woman implements Person {
    speak():string{
        return "woman";
    }
}

//人类工厂
class PersonFactory {
    static getPerson=(type:string) =>{
        if(type == "man"){
            return new Man();
        }
        else if(type == "woman"){
            return new Woman();
        }

        return {
            speak():string{
                return "";
            }
        };
    }
}

let man = PersonFactory.getPerson("man");
let woman = PersonFactory.getPerson("woman");

console.log(man.speak()); //man
console.log(woman.speak()); //woman

3.结语

当我们有个需要生成多种结构和功能类似的复杂对象的需求时，就应该考虑使用工厂模式。（这里工厂模式起到了清晰代码结构、解耦业务代码调用的功能）
而当我们的功能只是一个简单的对象特别是使用new就能创建的对象就不应该使用工厂模式。

具体的界限就是：（整理后业务代码+factory代码）复杂度 - （代码结构清晰+解耦业务代码调用）的好处 > 业务代码复杂度 ?不使用：使用；当模式带来的好处小于不使用的情况时则我们就不应该使用模式。