尚通 | 2021软件代码开发技术作业二| 读书笔记----软件设计原则、设计模式

这个作业属于哪个课程	https://edu.cnblogs.com/campus/gdgy/2021Softwarecodedevelopmenttechnology
这个作业要求在哪里	https://edu.cnblogs.com/campus/gdgy/2021Softwarecodedevelopmenttechnology/homework/11833
这个作业的目标	了解并学习设计模式

 

-本次作业内容

https://www.w3cschool.cn/zobyhd/

-设计模式的概念

设计模式（Design pattern）是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。 毫无疑问，设计模式于己于他人于系统都是多赢的；设计模式使代码编制真正工程化；设计模式是软件工程的基石脉络，如同大厦的结构一样。

-了解到的设计模式（并非全部）

　　1.工厂模式

　　　　意图：定义一个创建对象的接口，让其子类自己决定实例化哪一个工厂类，工厂模式使其创建过程延迟到子类进行。

　　　　主要解决：主要解决接口选择的问题。

　　　　何时使用：我们明确地计划不同条件下创建不同实例时。

　　　　如何解决：让其子类实现工厂接口，返回的也是一个抽象的产品。

　　　　关键代码：创建过程在其子类执行。

　　　　应用实例： 以客户购买车辆为例子，想要买车，不用关注工厂的制造过程，只需去下单然后提车即可

　　　　优点：   1、一个调用者想创建一个对象，只要知道其名称就可以了。

      　　　　　　 2、扩展性高，如果想增加一个产品，只要扩展一个工厂类就可以。

       　　　　　　3、屏蔽产品的具体实现，调用者只关心产品的接口。

　　　　缺点：每次增加一个产品时，都需要增加一个具体类和对象实现工厂，使得系统中类的个数成倍增加，在一定程度上增加了系统的复杂度，同时也增加了系统具体类的依赖。这并　　　　　　　　　　　　不是什么好事。

　　　　使用场景：  1、日志记录器：记录可能记录到本地硬盘、系统事件、远程服务器等，用户可以选择记录日志到什么地方。

           　　　　  　　2、数据库访问，当用户不知道最后系统采用哪一类数据库，以及数据库可能有变化时。

          　　　　　　   3、设计一个连接服务器的框架，需要三个协议，"POP3"、"IMAP"、"HTTP"，可以把这三个作为产品类，共同实现一个接口。

　　　　注意事项：作为一种创建类模式，在任何需要生成复杂对象的地方，都可以使用工厂方法模式。有一点需要注意的地方就是复杂对象适合使用工厂模式，而简单对象，特别是只需要通过 new 就可以完成创建的对象，无需使用工厂模式。如果使用工厂模式，就需要引入一个工厂类，会增加系统的复杂度。

意图：定义一个创建对象的接口，让其子类自己决定实例化哪一个工厂类，工厂模式使其创建过程延迟到子类进行。

　　　　2.抽象工厂模式

　　　　意图：提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。

　　　　主要解决：主要解决接口选择的问题。

　　　　何时使用：系统的产品有多于一个的产品族，而系统只消费其中某一族的产品。

　　　　如何解决：在一个产品族里面，定义多个产品。

　　　　关键代码：在一个工厂里聚合多个同类产品。

　　　　应用实例：工作了，为了参加一些聚会，肯定有两套或多套衣服吧，比如说有商务装（成套，一系列具体产品）、时尚装（成套，一系列具体产品），甚至对于一个家庭来说，可能有商务女装、商务男装、时尚女装、时尚男装，这些也都是成套的，即一系列具体产品。假设一种情况（现实中是不存在的，要不然，没法进入共产主义了，但有利于说明抽象工厂模式），在您的家中，某一个衣柜（具体工厂）只能存放某一种这样的衣服（成套，一系列具体产品），每次拿这种成套的衣服时也自然要从这个衣柜中取出了。用 OO 的思想去理解，所有的衣柜（具体工厂）都是衣柜类的（抽象工厂）某一个，而每一件成套的衣服又包括具体的上衣（某一具体产品），裤子（某一具体产品），这些具体的上衣其实也都是上衣（抽象产品），具体的裤子也都是裤子（另一个抽象产品）。

　　　　优点：当一个产品族中的多个对象被设计成一起工作时，它能保证客户端始终只使用同一个产品族中的对象。

　　　　缺点：产品族扩展非常困难，要增加一个系列的某一产品，既要在抽象的 Creator 里加代码，又要在具体的里面加代码。

　　　　使用场景： 1、QQ 换皮肤，一整套一起换。 2、生成不同操作系统的程序。

　　　　注意事项：产品族难扩展，产品等级易扩展。

　　　　3.服务定位器模式

　　　　服务定位器模式（Service Locator Pattern）用在我们想使用 JNDI 查询定位各种服务的时候。考虑到为某个服务查找 JNDI 的代价很高，服务定位器模式充分利用了缓存技术。在首次请求某个服务时，服务定位器在 JNDI 中查找服务，并缓存该服务对象。当再次请求相同的服务时，服务定位器会在它的缓存中查找，这样可以在很大程度上提高应用程序的性能。以下是这种设计模式的实体。

　　　　　　服务（Service） - 实际处理请求的服务。对这种服务的引用可以在 JNDI 服务器中查找到。

　　　　　　Context / 初始的 Context - JNDI Context 带有对要查找的服务的引用。

　　　　　　服务定位器（Service Locator） - 服务定位器是通过 JNDI 查找和缓存服务来获取服务的单点接触。

　　　　　　缓存（Cache） - 缓存存储服务的引用，以便复用它们。

　　　　　　客户端（Client） - Client 是通过 ServiceLocator 调用服务的对象。

　　　　4.解释器模式

　　　　　　意图：给定一个语言，定义它的文法表示，并定义一个解释器，这个解释器使用该标识来解释语言中的句子。

　　　　　　主要解决：对于一些固定文法构建一个解释句子的解释器。

　　　　　　何时使用：如果一种特定类型的问题发生的频率足够高，那么可能就值得将该问题的各个实例表述为一个简单语言中的句子。这样就可以构建一个解释器，该解释器通过解释这些句子来解决该问题。

　　　　　　如何解决：构件语法树，定义终结符与非终结符。

　　　　　　关键代码：构件环境类，包含解释器之外的一些全局信息，一般是 HashMap。

　　　　　　应用实例：编译器、运算表达式计算。

　　　　　　优点：           1、可扩展性比较好，灵活。

　　　　　　　　　　　　2、增加了新的解释表达式的方式。

　　　　　　　　　　　　3、易于实现简单文法。

　　　　　　缺点：           1、可利用场景比较少。

　　　　　　　　　　　　2、对于复杂的文法比较难维护。

　　　　　　　　　　　　3、解释器模式会引起类膨胀。

　　　　　　　　　　　　4、解释器模式采用递归调用方法。

　　　　　　使用场景：    1、可以将一个需要解释执行的语言中的句子表示为一个抽象语法树。

　　　　　　　　　　　　2、一些重复出现的问题可以用一种简单的语言来进行表达。

　　　　　　　　　　　　3、一个简单语法需要解释的场景。

　　　　　　注意事项：可利用场景比较少，JAVA 中如果碰到可以用 expression4J 代替

　　　　5.装饰器模式

　　　　　　意图：动态地给一个对象添加一些额外的职责。就增加功能来说，装饰器模式相比生成子类更为灵活。

　　　　　　主要解决：一般的，我们为了扩展一个类经常使用继承方式实现，由于继承为类引入静态特征，并且随着扩展功能的增多，子类会很膨胀。

　　　　　　何时使用：在不想增加很多子类的情况下扩展类。

　　　　　　如何解决：将具体功能职责划分，同时继承装饰者模式。

　　　　　　关键代码：    1、Component 类充当抽象角色，不应该具体实现。

　　　　　　　　　　　　2、修饰类引用和继承 Component 类，具体扩展类重写父类方法。

　　　　　　应用实例：    1、孙悟空有 72 变，当他变成"庙宇"后，他的根本还是一只猴子，但是他又有了庙宇的功能。

　　　　　　　　　　　　2、不论一幅画有没有画框都可以挂在墙上，但是通常都是有画框的，并且实际上是画框被挂在墙上。在挂在墙上之前，画可以被蒙上玻璃，装到框子里；这时　　　　　　画、玻璃和画框形成了一个物体。

　　　　　　优点：装饰类和被装饰类可以独立发展，不会相互耦合，装饰模式是继承的一个替代模式，装饰模式可以动态扩展一个实现类的功能。

　　　　　　缺点：多层装饰比较复杂。

　　　　　　使用场景：    1、扩展一个类的功能。

　　　　　　　　　　　　2、动态增加功能，动态撤销。

　　　　　　注意事项：可代替继承

-心得体会

            在我所学习的五种模式中，我觉得对我来说比较有用的就是工厂模式。在网页设计或者是游戏模型中，使用工厂模式，会让具有重复性质的个体减少占用的代码量，并且可以实现快速得到大量重复的个体。