软件构造复习--从设计模式说起

    考试将要来临了，我也改有写一些东西的必要了罢。

    设计模式是软件工程的基石，如同大厦的一块块砖石一样。项目中合理地运用设计模式可以完美地解决很多问题，每种模式在      现实中都有相应的原理来与之对应，每种模式都描述了一个在我们周围不断重复发生的问题，以及该问题的核心解决方案，这      也是设计模式能被广泛应用的原因。那么，面对纷繁复杂的设计模式，我们该如何理解并合理运用它们呢？让我们跟随前人的      脚步一点点的复(yu)习吧。

    我们现在所说的设计模式主要是基于以下的面向对象设计原则：

• 对接口编程而不是对实现编程。
• 优先使用对象组合而不是继承。

    现在的设计模式大约可以分为三大类：创建型模式（Creational Patterns）、结构型模式（Structural Patterns）、行为型模式（Behavioral Patterns）。

1

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

工厂模式（Factory Pattern） 抽象工厂模式（Abstract Factory Pattern） 单例模式（Singleton Pattern） 建造者模式（Builder Pattern） 原型模式（Prototype Pattern）

2

结构型模式 这些设计模式关注类和对象的组合。继承的概念被用来组合接口和定义组合对象获得新功能的方式。

适配器模式（Adapter Pattern） 桥接模式（Bridge Pattern） 过滤器模式（Filter、Criteria Pattern） 组合模式（Composite Pattern） 装饰器模式（Decorator Pattern） 外观模式（Facade Pattern） 享元模式（Flyweight Pattern） 代理模式（Proxy Pattern）

3

行为型模式 这些设计模式特别关注对象之间的通信。

责任链模式（Chain of Responsibility Pattern） 命令模式（Command Pattern） 解释器模式（Interpreter Pattern） 迭代器模式（Iterator Pattern） 中介者模式（Mediator Pattern） 备忘录模式（Memento Pattern） 观察者模式（Observer Pattern） 状态模式（State Pattern） 空对象模式（Null Object Pattern） 策略模式（Strategy Pattern） 模板模式（Template Pattern） 访问者模式（Visitor Pattern）

    设计模式的6个基本原则：

    1、单一职责原则（Single Responsibility Principle）：

    一个类只负责一个功能领域中的相应职责，或者可以定义为：就一个类而言，应该只有一个引起它变化的原因。

    2、里氏代换原则（Liskov Substitution Principle）：

    任何基类可以出现的地方，子类一定可以出现。

    3、依赖倒转原则（Dependence Inversion Principle）：

    抽象不应该依赖于细节，细节应当依赖于抽象。换言之，要针对接口编程，而非针对实现编程。

    4、接口隔离原则（Interface Segregation Principle）：

    客户端不应该依赖它不需要的接口；一个类对另一个类的依赖应该建立在最小的接口上。

    5、迪米特法则，又称最少知道原则（Demeter Principle）：

    一个软件实体应当尽可能少地与其他实体发生作用。

    6、开闭原则（Open Close Principle）：

    一个软件应对扩展开放、对修改关闭。

 

    下面列举一些常用(kao)的设计模式：

   1.单例模式

     基本概念：保证一个类仅有一个实例，并提供一个访问它的全局访问点。

    

   2.工厂模式

    基本概念：为创建对象提供过渡接口，以便将创建对象的具体过程屏蔽隔离起来，达到提高灵活性的目的。

    分为三类：

• 简单工厂模式Simple Factory：又称为静态工厂模式，不利于产生系列产品；

• 工厂方法模式Factory Method：又称为多形性工厂；

• 抽象工厂模式Abstract Factory：又称为工具箱，产生产品族，但不利于产生新的产品；

    这三种模式从上到下逐步抽象，并且更具一般性。将简单工厂模式可以看为工厂方法模式的一种特例。

    

    简单工厂模式的组成：

• 工厂类角色：这是本模式的核心，含有一定的商业逻辑和判断逻辑。在java中它往往由一个具体类实现。

• 抽象产品角色：它一般是具体产品继承的父类或者实现的接口。在java中由接口或者抽象类来实现。

• 具体产品角色：工厂类所创建的对象就是此角色的实例。在java中由一个具体类实现。

    

    工厂方法模式的组成：

• 抽象工厂角色： 这是工厂方法模式的核心，它与应用程序无关。是具体工厂角色必须实现的接口或者必须继承的父类。在java中它由抽象类或者接口来实现。

• 具体工厂角色：它含有和具体业务逻辑有关的代码。由应用程序调用以创建对应的具体产品的对象

• 抽象产品角色：它是具体产品继承的父类或者是实现的接口。在java中一般有抽象类或者接口来实现。

• 具体产品角色：具体工厂角色所创建的对象就是此角色的实例。在java中由具体的类来实现。

    总结

1. 简单工厂模式是由一个具体的类去创建其他类的实例，父类是相同的，父类是具体的。 

2. 工厂方法模式是有一个抽象的父类定义公共接口，子类负责生成具体的对象，这样做的目的是将类的实例化操作延迟到子类中完成。

3. 抽象工厂模式提供一个创建一系列相关或相互依赖对象的接口，而无须指定他们具体的类。它针对的是有多个产品的等级结构。而工厂方法模式针对的是一个产品的等级结构。

 

    

  3.建造(Builder)模式

    基本概念：是一种对象构建的设计模式，它可以将复杂对象的建造过程抽象出来（抽象类别），使这个抽象过程的不同实现        方法可以构造出不同表现（属性）的对象。

    Builder模式是一步一步创建一个复杂的对象，它允许用户可以只通过指定复杂对象的类型和内容就可以构建它们。用户不知        道内部的具体构建细节。Builder模式是非常类似抽象工厂模式。

            

    Buider模式由以下几部分组成：

• Builder：为创建一个Product对象的各个部件指定抽象接口。

• ConcreteBuilder：实现Builder的接口以构造和装配该产品的各个部件，定义并明确它所创建的表示，提供一个检索产品的接口

• Director：构造一个使用Builder接口的对象。

• Product：表示被构造的复杂对象。ConcreateBuilder创建该产品的内部表示并定义它的装配过程。

    Builder模式的应用

    在Java实际使用中，我们经常用到"池"(Pool)的概念，当资源提供者无法提供足够的资源，并且这些资源需要被很多用户反复        共享时，就需要使用池。"池"实际是一段内存，当池中有一些复杂的资源的"断肢"(比如数据库的连接池，也许有时一个连接会      中断)，如果循环再利用这些"断肢"，将提高内存使用效率，提高池的性能。修改Builder模式中Director类使之能诊断"断肢"断        在哪个部件上，再修复这个部件。

 

    

    4.观察者模式

      基本概念：观察者模式定义了一种一对多的依赖关系，让多个观察者对象同时监听某一主题对象。这个主题对象在状态发生        变化时，会通知所有观察者对象，使它们能够自动更新自己。观察者模式又叫发布-订阅(Publish/Subscribe)模式。

       

• Subject类：它把所有对观察者对象的引用保存在一个聚集里，每个主题都可以有任何数量的观察着。抽象主题提供一个接口，可以增加和删除观察着对象。

• Observer类：抽象观察者，为所有的具体观察者定义一个接口，在得到主题的通知时更新自己。

• ConcreteSubject类：具体主题，将有关状态存入具体观察者对象；在具体主题的内部状态改变时，给所有登记过的观察者发出通知。

• ConcreteObserver类：具体观察者，实现抽象观察者角色所要求的更新接口，以便使本身的状态与主题的状态相协调。    

    总结

    观察者模式何时适用？

• 当一个抽象模型有两个方面，其中一个方面依赖于另一方面。将这二者封装在独立的对象中可以使他们各自独立地改变和复用。

• 当对一个对象的改变需要同时改变其它对象，而不知道具体由多少对象有待改变。

• 当一个对象必须通知其他对象，而它又不能假定其他对象是谁，换言之，你不希望这些对象是紧密耦合的。让耦合的双方都依赖于抽象，而不是依赖于具体。

 

    

   5.适配器(Adapter)模式

     基本概念：适配器模式把一个类的接口变换成客户端所期待的另一种接口，从而使原本因接口不匹配而无法在一起工作的两         个类能够在一起工作。

      

      

• 目标(Target)角色：这就是所期待得到的接口。注意：由于这里讨论的是类适配器模式，因此目标不可以是类。

• 源(Adapee)角色：现在需要适配的接口。

• 适配器(Adaper)角色：适配器类是本模式的核心。适配器把源接口转换成目标接口。显然，这一角色不可以是接口，而必须是具体类。

     总结：

     适配器模式的优点

• 更好的复用性：系统需要使用现有的类，而此类的接口不符合系统的需要。那么通过适配器模式就可以让这些功能得到更好的复用。

• 更好的扩展性：在实现适配器功能的时候，可以调用自己开发的功能，从而自然地扩展系统的功能。

     适配器模式的缺点

　 过多的使用适配器，会让系统非常零乱，不易整体进行把握。比如，明明看到调用的是A接口，其实内部被适配成了B接口          的实现，一个系统如果太多出现这种情况，无异于一场灾难。因此如果不是很有必要，可以不使用适配器，而是直接对系统进      行重构。

 

   6.代理模式

     基本概念：为其他对象提供一种代理以控制对这个对象的访问。也可以说，在出发点到目的地之间有一道中间层，意为代理。

      

      在平时应用中，无可避免总要涉及到系统的授权或安全体系，不管你有无意识的使用Proxy，实际你已经在使用Proxy了。

 

    7.装饰模式

      基本概念：装饰模式(Decorator)，动态地给一个对象添加一些额外的职责，就增加功能来说，装饰模式比生成子类更为灵            活。

      

      

    上图是Decorator 模式的结构图,让我们可以进行更方便的描述:

• Component是定义一个对象接口，可以给这些对象动态地添加职责。

• ConcreteComponent是定义了一个具体的对象，也可以给这个对象添加一些职责。

    Decorator是装饰抽象类，继承了Component,从外类来扩展Component类的功能，但对于Component来说，是无需知道                Decorator存在的。ConcreteDecorator就是具体的装饰对象，起到给Component添加职责的功能。

    

   总结

 Decorator模式有以下的优缺点：

• 比静态继承更灵活与对象的静态继承相比，Decorator模式提供了更加灵活的向对象添加职责的方式，可以使用添加和分离的方法，用装饰在运行时刻增加和删除职责。使用继承机制增加职责需要创建一个新的子类，如果需要为原来所有的子类都添加功能的话，每个子类都需要重写，增加系统的复杂度，此外可以为一个特定的Component类提供多个Decorator，这种混合匹配是适用继承很难做到的。

• 避免在层次结构高层的类有太多的特征，Decorator模式提供了一种“即用即付”的方法来添加职责，他并不试图在一个复杂的可订制的类中支持所有可预见的特征，相反可以定义一个简单的类，并且用Decorator类给他逐渐的添加功能，从简单的部件组合出复杂的功能。

• Decorator 与它的Component不一样Decorator是一个透明的包装，如果我们从对象标识的观点出发，一个被装饰了的组件与这个组件是有差别的，因此使用装饰时不应该以来对象标识。

• 产生许多小对象，采用Decorator模式进行系统设计往往会产生许多看上去类似的小对象，这些对象仅仅在他们相互连接的方式上有所不同。

    

 

    参考文章：

     https://www.runoob.com/design-pattern/design-pattern-intro.html

     https://blog.51cto.com/12104971/2169591