Pl_Sun的博客

就在前几天，国家又出台了房地产政策，以促进那些有钱人买房。买房已经成为社会上一个热门话题，在中国人的心理，买房可是像成家立业一样的大事。那买房就能住吗？买房之后要达到人住的条件还需要进行装修。房屋装修又是一笔不菲的开销，花大价钱购买的房子那可得好好思考下装修相关事宜。自己肯定研究不明白，就去找装修公司。看到了吧，购买的房子如果想要达到居住的目的，还需要选择性的进行装修才行，除非你喜欢叙利亚风格。生活中像这样需要额外再投入使用的产品还有很多。再比如说购买奶茶时，你还可以选择多加波波，少加糖，少加冰等选项。

单一职责原则”要求一个类仅负责的一个不可分业务逻辑，但这并不意味着能够实现这部分业务逻辑的只能有一个类，业务逻辑可能是会因运行时数据而选择不同类。比如在日常工作中，请假审批可能受请假天数、请假类型等因素影响，而须由不同领导来负责审批。再比如在银行取钱时，取钱业务审批申请可能会受到你所取钱总数、存储类型等因素影响，而须由不同经理或职员来负责办理。这一类事情其实在代码世界中更加常见，比如参数校验可能受到请求类型、请求数据的不同而由不同类（订单接口包括用户风控校验、限购校验、门店合法性、商品合法性等）来负责。

小度，小度，热死了请打开空调~”，“小度，小度，主人回家了~”，“小度，小度，播放一首炸雷~”，像小度类似的智能产品正在逐步改善我们的生活，只要我们一声令下，产品立马执行，毫不拖延。就如同老板的命令一样，系统需接收到命令后经过一系列分析后，会自动选择执行哪些命令，而发令者完全不关心内部是执行了哪些动作以及哪个具体方法。比如“小度的主人回家了”，小度内部接受到指令后会自动分析出需要打开灯光，打开窗帘，打开中央空调，播放一首著名的萨克斯独奏-回家以及检查房门是否已关闭等内容。

每次乘坐高铁出行时，我都会像这样一个问题：这么多列车都可能通过这条轨道，会不会存在冲突的可能呢？，同样的，飞机的起飞和降落时对于道路的选择也会有冲突的可能。这些情况都会造成可怕的后果， 而阻止这种情况发生的就是机场调度中心。飞机在起飞和降落前都会请求机场调度中心，由机场调度中心来负责协调飞机、地面道路、摆渡车辆等。因此，机场调度中心就属于机场的总指挥，会统一协调各单位的运行状态，使得飞机能够安全、顺利起飞和降落。我们试想以下，如果没有机场调度中心的话，飞机在起飞时如何判断应该从哪个通道加速、起飞呢？

相信很多同学小时候都玩过《超级马里奥》这款游戏，不知道你是否还记得你曾经营救过的公主？你们在一起了吗？哈哈！小时候我家可没这个条件，经常跑到同学家里玩（或者看别人玩），可羡慕死我了。小的时候只知道玩，长大后才知道原来这么多关卡的马里奥竟然只占用40KB，我现在随手拍张照片也有个5MB左右呀！后来经过查阅资料才知道其中的道道：基本原理就如上所示，当然游戏内部还有一些其他优化措施，有兴趣的同学自行查阅。

组合和继承。从是否编译器确定代理类角度上看分为静态代理和动态代理。而其中动态代理的实现机制不同可分为JDK动态代理和CGLIB动态代理。在实际使用场景中，我们必须清楚的知道在什么场景下应该选用什么样的代理模式。

在前面几篇文章中，已经讲解了单例模式、工厂方法模式、抽象工厂模式，创建型还剩下一个比较重要的模式-建造者模式。在理解该模式之前，我还是希望重申设计模式的初衷，即。学习设计模式遗忘其初衷，注定无法理解其真正的深刻内涵。从创建型模式的名称上来看，这些都是为了解决创建对象相关的问题。单例模式解决了如何创建唯一对象的问题，工厂方法模式解决了对象创建过程的封装问题，抽象工厂模式解决了创建多个相关联对象的问题，那么不知道你之前是否有思考过，建造者模式是要解决什么问题吗？

生活中处处存在模版，模版定义了大的框架，具体内容由使用者填充即可，这给很多人的生活、工作带来了很大的遍历。你也可以想象生活中处处可见的其他“模版”，这是一个标准化的过程。在开发技术栈中，spring、mybatic等框架其实也是模版的体现，通过标准化模版式的约定简化开发成本，提升开发效率。因此，我们该怎么通过面向对象语言来体现这种标准化的过程(模版)呢？答案就是模版方法模式。

在经济学领域中，其主要研究对象(商品)之间根据消费依存关系可分为互补商品或替代商品，其中，互补商品如汽车与汽油、自行车与自行车胎、大饼和香肠、开水和泡面等。在面向对象的代码世界中，不同对象之间也存在这种类似相互依赖的关系【注：这种关系非指定为上面互补关系】，比如特斯拉汽车与新能源、奔驰汽车与92汽油、拖拉机与柴油，这种依赖关系是具有明显的依赖关系的。这意味着如果用户（客户端）获取的汽车对象种类不同，也意味着其所需要的能源种类也存在不同。思考这样一个问题，

基于面向对象语言开发中，免不得需要创建对象。前面讲解的"单例模式"也是如此，不过是要创建唯一的对象。本文要讲述“工厂方法模式”是要封装创建对象的过程。工厂，也称之为“制造厂”，用于创建具体的产品直接提供给外界使用。其实，这就是对产品的创建过程的封装，外界需要产品，那就通过工厂提供的途径获取。反映到代码世界中，如果对象的创建过程复杂，时，我们可不通过一个“工厂”来封装这个过程呢。工厂的具体代码表现形式要看封装的粒度。这里。这二者也分别代表着。

在前面的文章(设计模式-单例模式)中，我们分别介绍了四种单例设计模式，包括普通恶汉式单例、双重检查锁单例(DCL)、静态内部类单例以及枚举单例。但是，这四种模式还有一些问题我们没有仔细分析，以至于我们无法深入分析他们的优点以及可能存在的问题，更无法确定我们应该在什么场景下使用，在使用的时候我们有应该注意哪些方面。这些重要问题包括如下(但肯定不止，欢迎读者评论补充)：在普通饿汉式单例以及静态内部类单例，我们都利用JVM在并发加载类时肯定只会加载一次的特性，来保证单例对象有且仅有一次初始化动作。那有个问题是JV

面向对象语言讲究的是万物皆对象。通常流程是先定义可实例化类，然后再通过各种不同的方式创建对象，因此类一般可以实例化出多个对象。但是实际项目开发时，我们还是希望保证项目运行时有且仅包含一个实例对象。这个需求场景的出发点包括但不限于以下几个方面：数据源对象（创建连接池、权限验证等均十分消耗资源）、线程池对象（同一个线程池）、日志对象（防止日志覆盖）等等。

世界上没有任何一个项目是不需要迭代的，随着项目的发展壮大，会有越来越多的功能代码会被修改、添加、删除。据统计线上的生产事故90%都有由于变更引起的，因此为保证项目的迭代稳定性，我们需尽可能的遵守开闭原则。那开闭原则到底是什么？开和闭如何矛盾而统一呢？实际开发中该原则是否可执行？又该如何应用呢？

凡事皆有利弊，面向对象设计语言通过提供继承、多态等机制使得项目代码更具有复用性、可扩展性等优点，但是这些机制也存在一定的使用风险，比如继承的滥用、多态实现的不确定性等问题都有可能会引起重大线上事故。

代码世界中类间的耦合关系会直接影响代码可复用性、可读性、可扩展性等。这种耦合关系就如同人之间朋友关系一样，志不同道不合不应相于谋，否则最终只会落得个互相伤害的下场。代码组织时也应如此，应按照一定的原则处理好类之间的关系，否则就会导致恶性耦合只会使得项目代码越写越烂，难以维护。这个原则就是迪米特原则。

如同人体结构一样，项目代码也是需要有结构的，如原子逻辑块(不可再分代码块)、方法、类、模块等。结构要么是由成熟的框架搭建起来，要么自己手动划分，但是都需要。注意：这里所说的模块和项目代码结构中不完全一样，这里可以至结构中各个部分，比如原子逻辑块、方法等。按照生活的正常逻辑来说，上层模块依赖于下层模块（即，“依赖正置”）是没问题的，下层模块实现的功能就是提供给上层模块使用。但是由于需求的不断变化，下层模块功能的变动可能会影响到上层模块，继而导致整体功能的不可用。为解决这个问题，项目的各模块之间需遵循。

一般的系统设计都需要系统设计架构图，图中会将系统整体按照几个不同维度的模块进行拆分，以达到模块之间高内聚、低耦合的效果，协同完成系统的各项功能。同样，在应用程序设计的时候，我们也需要对模块、接口进行拆分，这种拆分的依据(原则)就是接口隔离原则。

在编程大环境中，评价代码组织方式质量的好坏涉及到各个方面，如代码的可读性、可维护性、可复用性、稳定性等各个方面。设计原则(SOLID)也是在这些方面可能出现的问题中总结出来的，虽然并不一定能够全部都满足原则要求，但是尽可能满足更能够提到代码组织质量。本文下面将逐步分析单一职责原则的具体含义以及应用。

学习设计模式随笔