weixin_63967970的博客

表示一个作用于某对象结构中的各元素的操作。它使你可以在不改变各元素的类的前提下定义作用于这些元素的新操作。

使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。将这个对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它为止。

定义了算法家族，分别封装起来，让他们之间可以互相替换，此模式让算法的变化，不会影响到使用算法的客户。策略模式属于对象行为模式，它通过对算法进行封装，把使用算法的责任和算法的实现分割开，并委派给不同的对象对这些算法进行管理。策略算法是形同行为的不同实现。

当一个对象的内在状态改变时允许改变其行为，这个对象看起来像是改变了其类。状态模式主要解决的是当控制一个对象状态转换的条件表达式过于复杂的情况。把状态的判断逻辑转移到表示不同状态的一系列类中，可以把复杂的判断逻辑简化。

定义：给定一个语言，定义它的文法的一种表示，并定义一个解释器，这个解释器使用该表示来解释语言中的句子。这个模式简单了解就行，所以不做过多总结。

在不破坏封装的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。这样以后就可以将该对象恢复到原先保存的状态。备忘录模式可以和原型模式组合使用。

用一个中介对象来封装一系列的对象交互。中介者使各对象不需要显示地相互引用，从而使其耦合松散，而且可以独立地改变他们之间的交互。

定义了一种一对多的依赖关系，让多个观察者对象同时监听某一个主题对象。这个主题对象在状态变化时，会通知所有的观察者对象，使得他们能够自动更新自己。目标和观察者：一对多单向依赖。通知的顺序绝不依赖于通知的顺序，多个观察者之间的功能是平行的。这个模式又叫发布-订阅模式，模型-视图模式，源监听器模式，从属者模式。

在迭代器模式中只需要用一个不同的迭代器来替换原有迭代器即可改变遍历算法，我们也可以自己定义迭代器的子类以支持新的遍历方式。就是说当需要访问一个聚集对象，而且不管这些对象是什么都需要遍历的时候，就应该考虑用迭代器模式。由于引入了迭代器，在原有的聚合对象中不需要再自行提供数据遍历等方法，这样可以简化聚合类的设计。在迭代器模式中，由于引入了抽象层，增加新的聚合类和迭代器类都很方便，无须修改原有代码，满足开闭原则。具体迭代器角色：实现抽象迭代器接口中所定义的方法，完成聚合对象的遍历，记录遍历的当前位置。

调用者/请求者（invoker）角色：要求命令对象执行请求，通常会持有命令对象，可以持有很对的命令对象。这个是客户端真正触发命令并且要求要执行的相应操作的地方，相当于使用命令对象的接口。定义：将一个请求封装为一个对象，使发出请求的责任和执行请求的责任分割开，这样两者之间通过命令对象进行沟通，这样方便将命令对象进行存储、传递、调用、增加与管理。实现者/接收者角色（receiver）：接收者，真正执行命令的对象，任何类都可能成为一个接收者，只要它能够实现命令要求实现的相应功能。，实现命令的撤销与恢复。

对每个不同的实现都需要定义一个子类，这会导致类的个数增加，系统更加庞大，设计也更加抽象。父类中的抽象方法由子类实现，子类执行的结果会影响父类的结果，这导致一种反向的控制结构，提高了代码阅读的难度。实现了反向控制，通过一个父类调用其子类的操作，通过对子类的具体实现扩展不同的行为，实现了反向控制，并符合开闭原则。算法的整体步骤固定，但其中个别部分易变时，这时候可以使用模板方法模式，将容易变的部分抽象出来，供子类实现。：实现代码复用，将相同的部分的代码放在抽象的父类中，而将不同的代码放入不同的子类中。

这是属于结构性模式的最后的最后一个了，一定要坚持继续复习！！奥里给！！希望能顺利熬过期末！！！

应用场景：需求中是体现部分与整体的结构以及用户可以忽略组合对象对单个对象的不同，统一的使用组合结构中的所有对象时，就应该考虑用组合模式。组合模式：将对象组合成树形结构以表示“部分-整体”的层次结构。组合模式使得用户对单个对象和组合对象的使用具有一致性。有两个要实现的例子，一个商品类别树，一个是公司管理的例子，这里以公司管理为例子。一些典型例子：绘图编辑器，图形捕捉系统，drow.io。缺点：很难限制组合中的组件类型。

典型的案例，就是一个追求者可以找一个代理人去给被追求者送礼物，实质还是追求者送的礼物，只是找人代替送礼物这件事情。代理模式：为其他对象提供一种代理以控制对这个对象的访问。

系统的数据和行为都正确，但是接口不符合时，我们应该考虑用适配器，目的是使控制范围之外的一个原有对象与某个接口匹配。适配器模式主要应用于希望复用一些现存的类，但是接口又与复用环境要求不一致的情况。将一个类的接口转换成客户希望的另外一个接口。emmmmmmm，感觉这个模式好像不是重点，也没布置啥作业，估计会出选择或者简答题。，本节主要就是对象适配器，采用对象组合的方式，更符合松耦合。缺点：过多使用适配器模式，会让系统凌乱，不容易整体进行把握。优点：更好的复用性，更好的扩展性。本质：转换匹配，复用功能。

外观模式：为子系统中的一组接口提供一个一致的界面，此模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。使用场景：当客户程序与抽象类的实现部分之间存在很大的依赖性。外观模式的外观类将客户端与子系统的内部复杂性分隔开。外观模式是迪米特法则的一个经典应用。缺点：不符合开闭原则。

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

这学期虽然科目少，但是工作量确实是大，真是头一次遇到这么紧凑的情况，既然无法避免，那就直面它！挑战一下极限！合成/聚合复用原则：尽量使用合成/聚合，尽量不要使用类继承。好处：优选使用对象的合成/和聚合将有助于保持每个类被封装，并被集中在单个任务上。这样类和类继承层次会保持较小规模，并且不太可能增长为不可控制的庞然大物。

截止到今天，创建者模式这一类别的模式已经全整理完了，一共包含5个，工厂方法模式，抽象工厂模式，单例模式，原型模式和建造者模式。还是太看的太慢，得加快进度了。就是使得建造代码与表示代码分离，由于建造者隐藏了产品是如何组装的，所以如果需要改变一个产品的内部表示，只需要再定义一个具体的建造者就可以了。如果使用了建造者模式，那么用户就只需要指定需要建造的类型就可以得到它们，而具体建造的过程和细节就不需要知道了。，所以建造者Builder类里的那些建造方法必须要足够普遍，以便为各种类型的具体建造者构造。

原型模式就是从一个对象再创建另外一个可定制的对象，而且不需要知道任何创建的细节。原型模式是用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象。原型模式内容比较少，今晚实现了简历的那个例子，深复制的问题。希望明天可以看到一个不一样的自己！今天状态比较差，效率低。

说真的，我还真没发现，这个模式和工厂方法模式到底有什么区别，无非就是多了几个抽象的产品而已。抽象工厂模式以一种倾斜的方式支持增加新的产品族。提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。本质：选择产品族的实现一个系统有多于一个的产品族，而系统只消费其中某一产品族。希望一个系统不应当依赖于产品类实例如何被创建、组合和表达的细节时。在抽象工厂模式中，产品族是指由同一个工厂生产的，位于不同产品等级结构中的一组产品，如海尔电器工厂生产的海尔电视机、海尔电冰箱。

简单工厂模式中，工厂类用于创建各种各样的产品，根据输入来的参数不同，创建出不一样的产品。但是如果有新的产品要加入，我们需要修改工厂类中的代码，这违背了开放封闭原则，并且对于工厂类有着较大的依赖。所以引出工厂方法模式。工厂方法模式是类的创建模式，其用意是定义一个创建产品对象的工厂接口，将创建产品工作推迟到子类中，**在工厂方法模式中，核心的工厂类不再不再负责所有产品的创建，而是将具体的创建工作交给子类去做。**这个核心类仅仅负责给出工厂必须是实现的接口，而不接触哪一个产品类被实例化这种细节。

当一个类“知道”另一个类时，可以用关联关系表示，比如企鹅和气候就是这种关系，企鹅需要知道气候，在企鹅类里边可以定义气候。这个用的也还是比较多的。聚合表示弱拥有关系，体现的是A对象可以包含对象B，但B对象不是A对象的一部分。部分和整体的关系，强拥有关系。用实心菱形+实线来表示。这个一般在客户端实现那里使用，其余的地方没见过有用这个表示的。比如动物依赖于氧气和水的关系就是依赖关系。+号表示公有，-表示私有，#表示保护。我感觉这个依赖关系模模糊糊的。这个也用的稍微多一点点吧。这个用的还是比较多的。

通常我们可以让一个全局变量使得一个对象被访问，但它不能防止实例化多个对象。最好的办法就是让类自身负责保存它的唯一实例。这个类可以保证没有其他实例可以被创建，并且它可以提供一个访问该实例的方法。2、必须创建自己的唯一实例。3、必须共享实例（static），给其他对象提供这一实例。一般有饿汉式单例（空间换时间）和懒汉式单例（时间换空间），：保证一个类仅有一个实例，并提供一个访问它的全局访问点。读取配置文件是典型的单例模式。打印机也是单例模式。输出结果为两个实例相同。

开放封闭的原则的核心：软件实体应该是可扩展的，而不可修改的。也就是，对扩展是开放的，对修改是封闭的。对扩展而言，如果我们需要新的方法，新的功能。我们可以对原本的类实现扩展，适应新的需求。但对于已经设计好的类，我们尽可能的不再去修改这个类。所以要求我们合理的抽象、分离出变化与不变化的部分，为变化的部分预留可扩展的方式。但是不能盲目的追求开放封闭原则，否则会造成系统的复杂度大大增大。