Estom的博客

设计模式之美 我发下所有的代码层面、软件层面、系统层面、多个系统组成的微服务层面… …这些不同粒度的实体，都遵循相同的设计模式。太美了，后续重新学习一下各个模式（看个视频数遍复习笔记） 参考文献 https://www.cnblogs.com/gaochundong/tag/Design%20Pattern/ 目录 设计模式分类 设计模式之间的关系 设计模式所支持的设计的可变方面 设计模式怎样解决设计问题 1 设计模式分类   目的 (Purpose) 创建型 (Creational) 结构型 (Structural) ...

单一职责原则（Single Responsibility Principle） 1 单一职责原则 （SRP：The Single Responsibility Principle） 为什么 因为每一个职责都是一个变化的中心。当需求变化时，这个变化将通过更改职责相关的类来体现。 如果一个类拥有多于一个的职责，则这些职责就耦合到在了一起，那么就会有多于一个原因来导致这个类的变化。对于某一职责的更改可能会损害类满足其他耦合职责的能力。这样职责的耦合会导致设计的脆弱，以至于当职责发生更改时产生无法预期的破坏。 低耦合高内聚 是什么 一个类应该有且只有一个变化的原因。 There should never be more than one reason for a class to change. 2 实例 例如，考虑下图中的设计。类图中显示 Rectangle 类包含两个方法，一个方法（Draw）负责在显示屏幕上绘制矩形，另一个方法（Area）负责计算矩形图形面积。 有两个不同的应用程序均使用了 Rectangle 类。一个应用为计算几何程序，它使用了 Rectangl...

1 开放封闭原则 OCP（Open Closed Principle） 为什么 “所有系统在其生命周期中都会进行变化，只要系统要开发一个版本以上这一点就需时刻记住。” All systems change during their life cycles. This must be borne in mind when developing systems expected to last longer than the first version. 在面向对象的设计中有很多流行的思想，比如说 “所有的成员变量都应该设置为私有（Private）” “要避免使用全局变量（Global Variables）” “使用运行时类型识别（RTTI：Run Time Type Identification，例如dynamic_cast）是危险的” 那么，这些思想的源泉是什么？为什么它们要这样定义？这些思想总是正确的吗？本篇文章将介绍这些思想的基础：开放封闭原则（Open Closed Principle）。 那么我们到底如何才能构建一个稳定的设计来面对这些变化，以使软件生命周期持...

1 里氏替换原则（Liskov Substitution Principle）为什么开放封闭原则（Open Closed Principle）是构建可维护性和可重用性代码的基础。它强调设计良好的代码可以不通过修改而扩展，新的功能通过添加新的代码来实现，而不需要更改已有的可工作的代码。抽象（Abstraction）和多态（Polymorphism）是实现这一原则的主要机制，而继承（Inheritance）则是实现抽象和多态的主要方法。 那么是什么设计规则在保证对继承的使用呢？优秀的继承层级设计都有哪些特征呢？是什么在诱使我们构建了不符合开放封闭原则的层级结构呢？这些就是本篇文章将要回答的问题。 是什么 里氏替换原则：所有引用基类的地方必须能透明地使用其子类的对象。使用基类对象指针或引用的函数必须能够在不了解衍生类的条件下使用衍生类的对象。 Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing ...

1 最少知识原则（迪米特法则）  概念迪米特法则：每一个软件单位对其他单位都只有最少的知识，而且局限于那些与本单位密切相关的软件单位 迪米特法则要求一个软件实体应当尽可能少地与其他实体发生相互作用。如果一个系统复合迪米特法则，那么当修改其中某一个模块时就会尽量少地影响其他模块。应用迪米特法则可以降低系统的耦合度。在类的设计上应该注意以下几点：在类的划分上应尽量创建松耦合的类，类之间的耦合度越低，越有利于复用；类的结构设计上，每一个类都应该降低其成员变量和成员函数的访问权限。 2 实例于对象 O 中的一个方法 m ，m 方法仅能访问如下这些类型的对象： O 对象自身； m 方法的参数对象； 任何在 m 方法内创建的对象； O 对象直接依赖的对象； 具体点儿就是，对象应尽可能地避免调用由另一个方法返回的对象的方法。现代面向对象程序设计语言通常使用 “.” 作为访问标识，LoD 可以被简化为 “仅使用一个点（use only one dot）”。也就是说，代码 a.b.Method() 违反了 LoD，而 a.Method() 则符合 LoD。打个比方，人可以命令一条狗行走，但是...

1 接口隔离原则概念 接口隔离原则：客户端不应该依赖那些它不需要的接口。 当一个接口太大时，应该将它根据需要分割成多个更细小的接口，每个接口仅承担一个相对独立的角色或功能，使用该接口的客户端仅需知道与之相关的方法即可。 但是，接口不能过小，否则系统中接口太多，不利于维护。一般而言，在接口中仅包含为某一类用户定制的方法即可。

1 合成复用原则概念 合成复用原则：优先使用对象组合，而不是通过继承来达到复用的目的。 根据UML类图关系，合成复用原则指导在软件设计时，优先使用关联、聚合和组合关系，尽量少用泛化（继承）。对象组合可以使系统更加灵活（黑箱复用），降低类与类之间的耦合度，一个类的变化尽可能不影响其他类（父类和子类耦合度高不高？）。如果要使用继承，则需考虑里氏代换原则和依赖倒转原则。继承关系会破坏系统的封装性，会将基类的实现细节暴露给子类（白箱复用），如果基类发生改变，那么子类的实现也不得不改变。

依赖倒转原则概念依赖倒转原则：高层模块不应该依赖低层模块，它们都应该依赖抽象。抽象不应该依赖于细节，细节应该依赖于抽象。 什么是高层，什么是低层呢？它们指的是继承（派生）中的基类子类关系，基类或者越抽象的类，层次越高。简单说，依赖倒转原则要求针对接口编程，不要针对实现编程。 依赖倒转原则要求再程序代码中传递参数时，或在关联关系中，尽量引用层次高的出现层类，即使用接口或抽象类来声明变量类型、参数类型声明、方法返回类型声明，以及数据类型转换等，而不要使用具体类来做这些事情。（其实这一点也符合里氏代换原则的指导意义，即对一个方法而言，返回基类的地方一定可以返回子类）。同样，依赖倒转原则设计的关键也在与抽象化设计。

整体和局部程序可大可小。任何一个程序都是一段完整的逻辑。程序可大可小，可以是一个函数、一个类、一个模块、一个应用、一个产品，但是无论在哪个维度，它都是一段完整的逻辑。 整体和局部的概念。要想写好一段逻辑，就要明白整体和局部的概念。框架完整了整体，库实现了局部一样，在编程开发过程中，我们也要完成每个程序的整体和局部，小到一个函数，大到一个产品都有自己的整体和局部。整体是面向目标和需求的，是局部依附的基础。局部是面向实现的，是整体的细节。 自己构建程序：自上而下的设计和自下而上的实现。在开发过程中也要遵循自上而下设计、自下而上实现，即要根据目标设计出整体的流程，置空细节。然后再每一个置空的细节处遵循相同的原则进行拆分，先设计总体的流程，然后实现具体的细节。 依赖第三方程序：框架和库。 框架是接管整个程序的执行流程，然后通过提供一些可以定制的接口，允许开发者定制局部的逻辑。 库是一个精小的组件，由开发者定制程序运行的主要流程，在任意时间使用库来完成局部的逻辑。 整体和局部的组装方式。整体和局部有多种组装的模式。最简单的就是同步调用，例如一个函数构建了流程，调用其他函数实现了某个细节...