【装饰+外观+享元】（自用）

1.1装饰者模式

引入

我们先来看一个快餐店的例子。

快餐店有炒面、炒饭这些快餐，可以额外附加鸡蛋、火腿、培根这些配菜，当然加配菜需要额外加钱，每个配菜的价钱通常不太一样，那么计算总价就会显得比较麻烦。

使用继承的方式存在的问题：

• 扩展性不好

  如果要再加一种配料（火腿肠），我们就会发现需要给FriedRice和FriedNoodles分别定义一个子类。如果要新增一个快餐品类（炒河粉）的话，就需要定义更多的子类。

• 产生过多的子类

装饰模式

定义：

​ 指在不改变现有对象结构的情况下，动态地给该对象增加一些职责（即增加其额外功能）的模式。

使用场景

• 当不能采用继承的方式对系统进行扩充或者采用继承不利于系统扩展和维护时。
• 避免使用子类进行扩展：当通过继承会导致类爆炸或无法实现灵活组合时，装饰器模式是一个很好的替代方案。
• 在不影响其他对象的情况下，以动态、透明的方式给单个对象添加职责。
• 当对象的功能要求可以动态地添加，也可以再动态地撤销时。

结构

装饰（Decorator）模式中的角色：

• 抽象构件（Component）角色 ：定义一个抽象接口以规范准备接收附加责任的对象。
• 具体构件（Concrete Component）角色 ：实现抽象构件，通过装饰角色为其添加一些职责。
• 抽象装饰（Decorator）角色 ： 继承或实现抽象构件，并包含具体构件的实例，可以通过其子类扩展具体构件的功能。
  • 抽象装饰类通常包含一个对具体构件的引用。这个引用允许装饰器在需要时将请求转发给原始对象。
  • 这个引用不是静态的，而是在运行时动态设置的。这意味着你可以在运行时动态地改变被装饰的对象，从而灵活地改变对象的行为。
  • 抽象装饰类通过实现与具体构件相同的接口，确保它可以像具体构件一样被使用。这使得装饰器可以在不修改现有代码的情况下，无缝地集成到现有系统中。
• 具体装饰（ConcreteDecorator）角色 ：实现抽象装饰的相关方法，并给具体构件对象添加附加的责任。

优缺点

优点：

• 装饰者模式可以带来比继承更加灵活性的扩展功能，使用更加方便，可以通过组合不同的装饰者对象来获取具有不同行为状态的多样化的结果。装饰者模式比继承更具良好的扩展性，完美的遵循开闭原则，继承是静态的附加责任，装饰者则是动态的附加责任。
• 装饰类和被装饰类可以独立发展，不会相互耦合，装饰模式是继承的一个替代模式，装饰模式可以动态扩展一个实现类的功能。

缺点：

• 使用装饰模式进行系统设计时将产生很多小对象，大量小对象的产生势必会占用更多的系统资源，在一定程度上影响程序的性能

• 比继承更加易于出错，排错也更困难，对于多次装饰的对象，调试时寻找错误可能需要逐级排查，较为烦琐

1.2外观模式

概念

​ 外观模式，又名门面模式，是一种通过 为多个复杂的子系统提供一个一致的接口，而使这些子系统更加容易被访问 的模式。该模式对外有一个统一接口，外部应用程序不用关心内部子系统的具体的细节，这样会大大降低应用程序的复杂度，提高了程序的可维护性。

​ 外观（Facade）模式是设计原则中“迪米特法则”的典型应用

迪米特法则（Law of Demeter，简称LOD），又称为“最少知识原则”，它的定义为：一个软件实体应当尽可能少的与其他实体发生相互作用。这样，当一个模块修改时，就会尽量少的影响其他的模块，扩展会相对容易。迪米特法则是对软件实体之间通信的限制，它对软件实体之间通信的宽度和深度做出了要求。

使用场景

• 当客户端与多个子系统之间存在很大的联系时，引入外观模式可将它们分离，从而提高子系统的独立性和可移植性。
• 对分层结构系统构建时，使用外观模式定义子系统中每层的入口点可以简化子系统之间的依赖关系。

⚠️ 何时使用：
1、客户端不需要知道系统内部的复杂联系，整个系统只需提供一个"接待员"即可。 2、定义系统的入口

⚠️ How to do?

客户端不与系统耦合，外观类与系统耦合。

结构

外观（Facade）模式包含以下主要角色：

• 外观（Facade）角色：为多个子系统对外提供一个共同的接口。
• 子系统（Sub System）角色：实现系统的部分功能，客户可以通过外观角色访问它。

电器总控案例

优缺点

优点

• 它对客户端屏蔽了子系统组件，减少了客户端所需处理的对象数目，并使得子系统使用起来更加容易

• 降低了子系统与客户端之间的耦合度，使得子系统的变化不会影响调用它的客户类，只需要调整外观类即可

• 一个子系统的修改对其他子系统没有任何影响，而且子系统的内部变化也不会影响到外观对象

缺点

• 不能很好地限制客户端直接使用子系统类，如果对客户端访问子系统类做太多的限制则减少了可变性和灵活性
• 如果设计不当，增加新的子系统可能需要修改外观类的源代码，违背了开闭原则

与其他模式的区别

适配器模式和外观模式共同点是将不好用的接口适配成好用的接口。但是适配器模式是将一个接口通过适配来间接转换为另一个接口，外观模式主要是提供一个整洁的一致的接口给客户端。

与抽象工厂模式的异同

抽象工厂模式可以与外观模式一起使用以提供一个接口，用来以一种子系统独立的方式创建子系统对象。

两者都旨在简化客户端代码，提高系统的可维护性和可扩展性。通过抽象或封装复杂逻辑，客户端可以更容易地理解和使用系统。
两者都涉及到接口和抽象类的使用，以实现代码的解耦和复用。

一般仅需要一个Facade对象，因此Facade对象通常属于Singleton模式。

1.3享元模式

应用

• 如果一个软件系统在运行时所创建的相同或相似对象数量太多，将导致运行代价过高，带来系统资源浪费、性能下降等问题

• 为了避免系统中出现大量相同或相似的对象，同时又不影响客户端对这些对象进行操作—> 享元模式

概念

​ 运用共享技术来有效地支持大量细粒度对象的复用。它通过共享已经存在的对象来大幅度减少需要创建的对象数量、避免大量相似对象的开销，从而提高系统资源的利用率。

结构

享元（Flyweight ）模式中存在以下两种状态：

1. 内部状态，即不会随着环境的改变而改变的可共享部分。
2. 外部状态，指随环境改变而改变的不可以共享的部分。享元模式的实现要领就是区分应用中的这两种状态，并将外部状态外部化。

享元模式的主要有以下角色：

• 抽象享元角色（Flyweight）：通常是一个接口或抽象类，在抽象享元类中声明了具体享元类公共的方法，这些方法可以向外界提供享元对象的内部数据（内部状态），同时也可以通过这些方法来设置外部数据（外部状态）。
• 具体享元（Concrete Flyweight）角色 ：它实现了抽象享元类，称为享元对象；在具体享元类中为内部状态提供了存储空间。通常我们可以结合单例模式来设计具体享元类，为每一个具体享元类提供唯一的享元对象。
• 非享元（Unsharable Flyweight)角色 ：并不是所有的抽象享元类的子类都需要被共享，不能被共享的子类可设计为非共享具体享元类；当需要一个非共享具体享元类的对象时可以直接通过实例化创建。（有外部状态，多的时候可以进行抽象）
• 享元工厂（Flyweight Factory）角色 ：负责创建和管理享元角色。当客户对象请求一个享元对象时，享元工厂检査系统中是否存在符合要求的享元对象，如果存在则提供给客户；如果不存在的话，则创建一个新的享元对象。

例：俄罗斯方块

每种图形可能出现多次，且有多种颜色，对象很多，占用过多内存空间

颜色–外部状态，通过传参实现

AbstractBox 抽象享元类
	getShape() 获取图形--抽象方法，由子类实现
	display() 具体方法，把颜色和形状输出到控制台
	
IBox、LBox、OBox 具体享元类
I形 L形 O形
	getShape() 重写父类抽象方法，返回具体图形
	
BoxFactory 享元工厂类
只需创建一个对象，融入了简单的懒汉式单例模式
	map (HashMap) 用于存储图形名称和对象 key-value
	factory 保存由自身创建的对象
	
	BoxFactory() 构造器私有
	getInstance() 提供一个方法获取该工厂类对象
	getShape() 根据名称获取图形对象	

优缺点

优点

• 可以减少内存中对象的数量，使得相同或者相似的对象在内存中只保存一份，从而可以节约系统资源，提高系统性能

• 外部状态相对独立，而且不会影响其内部状态，从而使得享元对象可以在不同的环境中被共享

缺点

• 使得系统变得复杂，需要分离出内部状态和外部状态，这使得程序的逻辑复杂化

• 为了使对象可以共享，享元模式需要将享元对象的部分状态外部化，而读取外部状态将使得运行时间变长