[GN] 设计模式—— 创建型模式

---

创建型模式

单例模式 – 确保对象唯一性

用TaskManager类。通过以下三步进行重构

1. 为了确保TaskManager实例的唯一性，禁止外部直接new来创建对象。需将构造函数改为private
2. 类变成私有的了，所以外部访问该类对象，需要类内建TaskManager类型的私有静态成员变量tm。供外部访问
3. 增加一个公有的静态方法、外界去使用tm 去实例化。 [注意 该方法要public]

单例模式有3个要点:

• 某个类只能有一个实例;
• 它必须自行创建这个实例;
• 它必须自行向整个系统提供这个实例。

上述代码在多线程时候，会出现 创建多个实例。提供两种解决方式

饿汉式

定义静态变量的时候实例化单例类

懒汉式

不自行实例化，延时加载。
采取双标志

为了避免多个钱程同时调用getInstonce ( ）方法，可以使用关键守synchronized
如果使用双重检查锁定来实现懒汉式单例类，需要在静态成员变量instonce之前增加修饰符volatile，被volatile修饰的成员变量可以确保多个线程都能够正确处理

优缺点

优点： 提供了对唯一实例的受控访问，可以严格控制客户怎么样访问它
缺点：没有抽象层，难以扩展； 单例类职责过重，一定程度违背单一职责原则；

使用场景

1. 客户调用类的单个实例只允许使用一个公共访问点。除了该公共访问点，不能通过其他途径访问该实例。
   2.系统要求提供一个唯一的序列号生成器或贵源管理器，或着需要考虑赉源消耗太大而只允许创建一个对象。

---

提示：以下是本篇文章正文内容，下面案例可供参考

简单工厂模式

例子：

图表库举例：

完整代码：

Chart接口充当抽象产品类，其子类HistogromChort、 PieChart和Linehart充当具体产品类，Chart-Factory充当工厂类。

优化

每更换一个Chart对象都需要修改客户端代码中静态工方法的参数，客户端代码将要重新编译。

可以将参数写到XML中，代码中只需要读取配置文件字符。

优缺点

优点
(1) 工厂类包含必要的判断逻辑，决定在什么时候创建哪一个产品类的实例。客户端仅仅“消费”产品。简单工厂模式实现了对象创建和使用的分离。
(2）客户端无须知道所创建的具体产品类的类名，只需要知道具体产品类所对应的参数即可。
(3）通过引入配置文件，可以在不修改任向客户端代码更换和增加新的具体产品类。

缺点
( l)由于工丁厂类集中了所有产品的创建逻辑，职责过重。
(2）使用简单工厂模式势必会增加系统中类的个数（引入了新的工丁厂类）。
(3）系统扩展困难。一旦添加新产品就不得不修改工厂逻辑。

适用场景

• 工厂类负责创建的对象比较少。由于创建的对象较少，不会造成工厂方法中的业务逻辑太过复杂。
• 客户端只知道传入工丁厂类的参数，对于如同创建对象并不关心。

工厂方法模式–多态工厂的实现

简单工厂模式下存在

• 工厂类过于庞大，包了大量的f…else…代码，导致维护和测试难度增大。
• 系统扩展不灵活，如果增加新类型的日志记录器，必须修改静态工厂方法的业务逻辑，违反了开闭原则。

简单工厂模式只有一个工厂 需要知道每个产品创建细节

由此工厂方法产生：

例子

图表库举例：

ConcreteFactory 具体工厂； Factory 抽象工厂
ConcreteProduct 具体产品 与 具体工厂一一应对； Product 抽象产品

完整代码：

优缺点

优点

• 用户只需要关心所需产品对应的工厂，无须关心创建细节，甚至无须知道具体产品类的类名。
• 它能够让工厂可以自主确定创建同种产品对象，而如同创建这个对象的细节则究全封装在具体工厂内部。
• 加入新产品时，无须修改抽象工厂和抽象产品提供的接口，无须修改客户端，也无须修改其他的具体工厂和具体产品，而只要添加

缺点

• 在添加新产品时，需要编写新的具体产品类，而且还要提供与之对应的具体工厂类，在一定程度上增加了系统的复杂度。
• 考虑到系统的可扩展性，需要引入抽象层，在客户端代码中均使用抽象层进行定义，增加了系统的抽象性和理解难度

适用场景

• 客户端不知道其所需要的对象的类。在工厂方法模式中，客户端不需要知道具体产品类的类名，只需要知道所对应的工厂即可，具体的产品对象由具体工厂类创建，可将具体工厂类的类名存储在配置文件或数据库中。
• 抽象工厂类通过其子类来指定创建哪个对象。在工厂方法模式中，抽象工厂类只需要提供一个创建产品的接口，而由其子类来确定具体要创建的对象，利用面向对象的多态性和里氏代换原则