第六次作业
第六次作业
结构型模式描述了如何把类和对象组合起来以形成更大的结构。
类模式和对象模式的区别为：1. 类模式描述的是如何能够通过继承来提供更加游泳的编程接口。2，对象模式描述的则是如何通过使用对象组合或者对象对其他的对象的包含来创建更大型的结构。
例如：适配器模式可以用来使得一个类的接口与其他的类相匹配，就会使得编程更加容易。组合模式就是一种对对象的组合，组合中每个对象可能是一种简单的对象，也可能本身就是组合对象。
代理模式往往是一种简单的对象，其用来代替以后可能会被调用的一个更加复杂的对象，例如当程序运行于网络环境中的时候，就可能用到这种更加复杂的对象。
享元模式用于共享对象，在该模式中，每个实例都不包含自己的状态，而是把状态存储在外部。当存在许多的实例，但是只有少数集中不同的类型时，这种做法提供了一种经济的对象共享，可以节省空间。
外观模式的作用是用单个类来代表整个的一个系统，桥接模式则是分离对象的接口和实现，这样就可以分别对他们做出改动。装饰漆模式，该模式可以动态的给对象添加上一些职责。
Chain of Responsibility模式：
责任链的作用
-
弱化了发出请求的人和处理请求的人之间的关系
发出请求的人只需要向第一个具体的处理者发送请求，然后就可以不用管了，处理者会在责任链上自己寻找处理的方法。
这样就解耦了处理者和请求者之间的关系。
如果我们不采取责任链模式，那么请求者就必须要很清楚哪个处理者能处理它的请求，就必须对所有的处理者都有所了解，类似于上帝视角，然而在实际中，要求请求这了解这么多是不实际的 -
可以动态的改变责任链
责任链还有的好处就是可以动态的改变责任，删除或者添加或者改变顺序。 -
让各个处理者专注于实现自己的职责
责任链模式同时还做到了处理者之间的解耦，处理者自己专注于自己的处理逻辑就好，不管其他处理者干什么。 -
推卸责任也可能导致处理延迟
我们可以责任链模式需要在责任链上传播责任，直至找到合适的处理对象。这样提高了程序的灵活性，但同时也出现了处理的延迟，因为有一个寻找的过程。所以需要低延迟的情况下，就不应该使用责任链模式
责任链模式的应用
在视窗系统中，经常会使用到责任链模式，尤其是事件的处理，熟悉javascript开发的朋友，可能会知道，浏览器中的事件有冒泡机制，，就是事件的是向父控件传播的，如果自己处理不了，就会传播给父控件去处理。
Memento模式：
备忘录模式也是一种比较常用的模式用来保存对象的部分用于恢复的信息，和原型模式有着本质的区别，广泛运用在快照功能之中，另外我们知道了宽接口和窄接口，这里的接口就是指的方法，没有其他意思，以及类的可见性。同样的使用备忘录模式可以使得程序可以组件化，比如打算多次撤销当前的状态，以及不仅可以撤销而且可以将当前的状态保存到文件之中的时候，我们不需要修改Gamer的代码就能做到，职责明确是一种非常重要的是软件工程思想。
状态模式（State），当一个对象的内在状态改变时允许改变其行为，这个对象看起来像是改变了其类。
策略模式是对算法的包装，是把使用算法的责任和算法本身分割开，委派给不同的对象管理。策略模式通常把一个系列的算法包装到一系列的策略类里面，作为一个抽象策略类的子类。用一句话来说，就是："准备一组算法，并将每一个算法封装起来，使得它们可以互换。
Strategy模式
优点:1代码清晰,相比于大量的if-else,使用策略者模式,使得代码更加的清晰优雅
2扩展性好:对于添加新的功能,修改逻辑等扩展,使用策略者模式能够很好的支持
缺点:1增加了程序的复杂程度
2在各种策略实例的时候,依然存在细节,但是可以通过依赖注入控制反转很好的解决
Visitor模式：表示一个作用于某对象结构中的各元素的操作。它使你可以在不改变各元素的类的前提下定义作用于这些元素的新操作。
第七次作业
开闭原则：对扩展开放，对修改关闭
依赖倒转原则：高层模块不应该依赖底层模块，它们都应该依赖抽象；要针对抽象层编程，而不要针对具体类编程。
单一职责原则：类的职责要单一，不能将太多的职责放在一个类中
里氏代换原则：使用基类对象的地方都可以使用子类对象，因此在程序中尽量使用基类类型来对对象进行定义，而在运行时再确定其子类类型，用子类对象来替换父类对象。
合成复用原则：指在一个新的对象里通过组合、聚合关系来使用一些已有的对象，使之成为新对象的一部分；新对象通过调用已有对象的方法达到复用其已有功能的目的。简言之：要尽量使用组合/聚合关系，少用继承。
迪米特原则：指一个软件实体应当尽可能少的与其他实体发生相互作用。这样，当一个模块修改时，就会尽量少的影响其他的模块，扩展会相对容易，这是对软件实体之间通信的限制，它要求限制软件实体之间通信的宽度和深度。
接口隔离原则：指使用多个专门的接口，而不使用单一的总接口。 一旦一个接口太大，则需要将它分割成一些更细小的接口，使用该接口的客户端仅需知道与之相关的方法即可。
设计模式建立在对系统变化点的基础上进行，哪里有变化点，哪里应用设计模式。
设计模式应该以演化的方式来获得，系统的变化点往往是经过不断演化才能准确定位。
不能为了模式而模式，设计模式是一种软件设计的软力量，而非规范标准。不应夸大设计模式的作用。
