设计模式

设计模式

工厂模式

不依赖于new函数返回一个对象，而创建一个工厂类，在工厂中有一个工厂方法，根据给定的参数返回相应的产品，这样，需要不同产品的时候，可以通过工厂类的同一方法输入不同类名即可获取到相应的对象。
但是，显然，一堆if else之类的东西，显然违背了开闭原则，当需要新的产品，则需要修改工厂方法。

这张图就是一个典型的工程模式UML，将所有产品进行抽象，抽象为一个抽象类Product，然后再不同产品中具体实现产品特性，形成Product1，Product2，再构建一个工厂类，其中根据不同产品设计不同的工厂方法，返回相应的产品（父类），而非具体产品。

抽象工厂模式

这是UML，可以看到，它对工厂类也进行了抽象，每个工厂都会生成特定的产品族，图中，都生产A和B，A和B有其具体子类，例如，同样是工厂，联想和惠普都生产键盘和鼠标，则我们可以将两个工厂抽象为一个抽象工厂，工厂会返回一个鼠标，一个键盘，在联想的实现中，返回联想鼠标和联想键盘，惠普工厂返回惠普鼠标和惠普键盘，键盘和鼠标作为抽象接口，可以有不同品牌的实现。
如果我们需要增加某一类产品，只需要增加某个Product的抽象类，增加相应的子类（不同品牌），然后在抽象工厂，具体工厂中加入相应的方法即可
如果需要增加工厂，如增加华为，则只需要增加一个具体工厂，然后在鼠标和键盘的子类中增加华为鼠标和华为键盘即可。

Builder模式

我们有一个产品，比如说，电脑，电脑有CPU，显卡，内存 3个属性，有相应的set方法。然后设计一个Builder类（抽象接口），Builder负责组装，也就是对电脑的组件进行set，set1，set2，set3，我们要组装两种配置的电脑，高配和低配，然后我们就implement Builder类，添加一个Computer属性，然后开始对这个computer一顿set1，set2，set3，具体实现中加入相应具体配件，这个时候我们需要一个导购，导购中有一个Builder的属性，导购负责调用Builder的set方法进行construct，然后返回给用户一个computer。当然，你也可以在Builder中加入一个Construct的方法，用户直接调用Builder，没有中间商赚差价。

Bridge模式

这是PPT中的图，并不是很好理解，于是重新找了一个图

深层继承，最上面是Computer，然后是desktop，laptop，pad，然后是不同厂家的desktop
我们可以知道，一个电脑有两个属性，分别是厂家和类型，如果我们使用桥模式，就可以简化这种深层继承，比如说，我们用imp实现类型，Computer具有imp的属性，就具有了类型这个属性，然后在实现Computer这个抽象类的时候，再在方法和属性中加入具体厂家的属性和方法。就将二者联系起来了

Proxy模式

https://www.cnblogs.com/meet/p/5116464.html 这个博主写得很好
大概例子就是，代理就是经纪人，实际对象就是明显，客户需要找一个明星唱，跳，rap，于是他找到了经纪人，经纪人有一个属性，就是自己负责的明星，这是利用了委托的机制，有了这个属性，经纪人就可以调用明星这个属性实现：唱，跳，rap。

Composite模式

文件夹中有文件，也有文件夹，文件中不可以再添加东西，而文件夹中可以，但是我们可以将其进行抽象，表示他们都是一个文件夹中的条目，是一个component，于是就有了上述UML，Leaf是向文件这类component，其他Component还可以继续添加，递归添加组件。

Observer 模式

一共有四个角色，其实只有两个，但是为了以后的扩展，抽象出两个抽象类或接口
对象（抽象类）
实际对象（具体实现）
观察者（接口）
具体观察者（实现）
对象抽象类管理一个观察者列表，并有添加观察者和删除观察者两个功能
具体对象类中，添加对象的具体属性，以及对属性的set和get，当状态变化时，会遍历观察者列表中的每个观察者，调用其中的update属性去更新观察者的观察状态。

介者模式

玩狼人杀的时候，需要一个人来当上帝，否则的话，会导致一些权限管理上的麻烦，以及药水等资源数量的计算错误，女巫用完了药水，但他说没有用完，别人也不知道用没用完，只能选择原谅她咯。
玩斗地主的时候，可能会有算错钱的情况，A给B筹码，结果A算错了，AB的筹码都错了，就会影响最后的结果。
这个时候就需要引入介者模式

这PPT上的截图实在太小了。。。
和观察者不同，每个成员既可以接受信息，也可以发送信息，当然，要接受中介的管理，只负责发送给中介，中介再发给目标。

Visitor模式

这个模式将数据结构以及其上的操作分离，如果需要增添新的方法，则增添visitor中的类即可。