大话设计模式

---

工作已然2年，回想过去，不堪入目，现在依然记得第一段代码，是copy来的，而且是巨垃圾的代码，以至于养成了不好的习惯，经过一年的工作，觉得自己不应该如此下去，因此开始了java工程师的成长之路：疯狂看书，而这些书应该是一开始工作就好好读的，无奈第一份工作根本没有培养环境；当然如果能一毕业就进入alibaba，腾讯，网易，百度等一众互联网大佬公司，也是要靠自己的，哈哈！

当然本书的叙述模式还是很轻松幽默的，只是笔记中需要记录一下example，以备复习，提炼水平。

简单工厂模式

这里举了一个面试的例子，例子中A去笔试，回答一个计算器程序的问题。一开始自然是一锅端的写在了一起的，如下：

这应该是刚毕业的大学生的答案，只是单纯的回答问题，没有考虑其他；可想而知，面试官想要的答案并不是这样。

下面的例子是针对代码规范修改的。

这应该是最表面的优化了吧，其实就被除数为0这个梗，我都没有一直铭记，总是出错了才去改；其次就是代码规范，好的代码需要好的代码规范，不然维护的成本很大，就好比英国人读懂中国人的思维一样，本人在刚工作的时候也没有很注意，不过还好年轻不怕失败！

下面是把业务和功能分离，使程序具有可维护，可扩展，可复用，灵活性好。这里就需要用到面向对象中封装，继承和多态的方法降低耦合度。

首先是是业务的封装：

接着是去耦合：

最后就是简单工程模式

附上UML的用法图，不多bb。

商场促销–策略模式

这里书中例举了一个商场打折促销模式的结账单软件。

首先是计算商品的总价格。文中的小菜就在类中直接计算了。

然后超市就有了打折这一个功能了。小菜这里就把打折的类型写死了，然后根据没中打折方式，计算最后的价格。这里就存在问题了，面对超市这种活动形式不确定的场所，这种方法是灾难性的，因为每次都需要更新硬件机器，以及后台服务。比如说，满300减50，积分制等等活动。

先看一下简单工厂模式：

面向对象的编程，并不是越多越好，类的划分是为了封装，但分类的基础是抽象，具有相同的属性和功能的对象的抽象集合才是类。

UML图

再看一下策略模式：

UML图

来看一下策略模式的代码

显然这种策略模式是一种倒退，因为使得客户端要经常更改。

简单工厂模式和策略模式的融合

单一职责原则

如果一个类承担的职责过多，就等于把这些职责耦合在一起，一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力。这种耦合会导致脆弱的设计，当变化发生时，设计会遭受到意想不到的破坏。

考研求职两不误–开放-封闭原则

在我们最初编写代码时，假设变化不会发生。当变化发生时，我们就创建抽象类来隔离以后发生的同类变化。

面对需求，对程序的改动是通过增加新代码进行的，而不是更改现有的代码。

依赖倒转原则

一个软件实体如果使用的是一个父类的话，那么一定适用于其子类，而它察觉不出父类和子类对象的区别。

依赖倒转其实可以说是面向对象设计的标志，用哪种语言来编写程序不重要，如果编写时考虑的都是如何针对抽象编程而不是针对细节编程，即程序中所有的依赖关系都是终止于抽象类或者接口，那就是面向对象的设计，反之就是过程化的设计了。

装饰模式

装饰模式UML

具体的实例代码：

装饰模式提供了一个非常好的解决方案，把每个要装饰的功能放在单独的类中，并让这个类包装它所需要装饰的对象，因此，当需要执行特殊行为时，客户代码就可以在运行时根据需要有选择地，按顺序地使用装饰功能包装对象了。

代理模式

UML图

工厂方法模式

计算器的工厂模式

简历复印–原型模式

深拷贝与浅拷贝

模板方法模式

迪米特法则

外观模式

建造者模式

观察者模式

观察者模式不足就是所有观察者的行为必须一致

事件委托

Java中需要利用反射实现委托类的开发

抽象工厂模式

状态模式

状态模式主要解决的是当控制一个对象状态转换的条件表达式过于复杂时的情况。把状态的判断逻辑转移到表示不同状态的一系列类当中，可以把复杂的判断逻辑简化。

适配器模式

适配器模式主要应用于希望复用一些现存的类，但接口又与复用环境要求不一致的情况

适配器模式主要就是在双方都不太容易修改的时候再使用适配器模式适配，而不是一有不同就使用它。

备忘录模式

Memento封装了要保存的细节。更改细节也不影响客户端。

备忘录模式适用于功能比较复杂的，但需要维护或记录属性历史的类。

组合模式

应用在此类整体与部分可以一致对待的问题

迭代器模式

迭代器（Iterator）模式就死分离了集合对象的遍历行为，抽象出一个迭代器类来负责，这样既可以做到不暴露集合的内部结构，又可让外部代码透明地访问集合内部的数据。

单例模式

多线程访问时涉及锁的问题–双重锁定。

桥接模式

桥接模式UML

实现系统可能有多角度分类，每一种分类都有可能变化，那么就把这种多角度分离出来让它们独立变化，减少它们之间的耦合。

命令模式

职责链模式

实例

中介者模式

首先来看一下中介者模式的实例：联合国

代理之后

中介者模式一般应用于一组对象以定义良好但是复杂的方式进行通信的场合。

享元模式

内部状态与外部状态

如果一个应用程序使用了大量的对象，而大量的这些对象造成了很大的存储开销时就应该考虑使用；还有就是对象的大多数状态可以外部状态，如果删除对象的外部状态，那么可以用相对较少的共享对象取代很多组对象，此时可以考虑使用享元模式。

解释器模式

当有一个语言需要解释执行，并且你可以将该语言中的句子表示为一个抽象语法树时，可使用解释器模式。

访问者模式

实例：

访问者模式适用于数据结构相对稳定的系统，它把数据结构和作用于结构上的操作之间的耦合解脱开，使得操作集合可以相对自由的演化。

本书总结

暂未更新