java设计模式六大原则、java设计模式几种 收藏 0

Java设计模式：23种设计模式全面解析（超级详细）

设计模式（Design Pattern）是前辈们对代码开发经验的总结，是解决特定问题的一系列套路。它不是语法规定，而是一套用来提高代码可复用性、可维护性、可读性、稳健性以及安全性的解决方案。 1995 年，GoF（Gang of Four，四人组/四人帮）合作出版了《设计模式：可复用面向对象软件的基础》一书，共收录了 23 种设计模式，从此树立了软件设计模式领域的里程碑，人称「GoF设计模式」。

这 23 种设计模式的本质是面向对象设计原则的实际运用，是对类的封装性、继承性和多态性，以及类的关联关系和组合关系的充分理解。当然，软件设计模式只是一个引导，在实际的软件开发中，必须根据具体的需求来选择：

• 对于简单的程序，可能写一个简单的算法要比引入某种设计模式更加容易；
• 但是对于大型项目开发或者框架设计，用设计模式来组织代码显然更好。

本系列文章虽然命名为“Java设计模式”，但是设计模式并不是 Java 的专利，它同样适用于 C++、C#、JavaScript 等其它面向对象的编程语言。Java 是典型的面向对象的编程语言，所以本系列文章以 Java 为基础来讲解这 23 种设计模式.

万字总结：设计模式七大原则

设计模式是对软件设计普遍存在的问题，所提出的解决方案。

与项目本身没有关系，不管是电商，ERP，OA 等，都可以利用设计模式来解决相关问题。

当然如果这个软件就只有一小部分人用，并且功能非常简单，在未来可预期的时间内，不会做任何大的修改和添加，即可以不使用设计模式。但是这种的太少了，所以设计模式还是非常重要的。

使用设计模式的最终目的是“高内聚低耦合”。

• 代码重用性：相同功能的代码，不多多次编写
• 代码可读性：编程规范性，便于其他程序员阅读
• 代码可扩展性：当增加新的功能后，对原来的功能没有影响

设计模式有7大原则，具体如下，即这些不仅是设计模式的依据，也是我们平常编程中应该遵守的原则。

见名知意，我们设计的类尽量负责一项功能，如A类只负责功能A，B类只负责功能B，不要让A类既负责功能A，又负责功能B，这样会导致代码混乱，容易产生bug。

Single类：

Vehicle类：

运行结果：

我们看下运行结果，汽车是在公路上开，但是轮船和飞机并不是在公路上。因为Vehicle类负责了不止一个功能，所以该设计是有问题的。

对于上面的例子，我们采用单一职责原则重写一下，将Vehicle类拆分成三个类，分别是Car，Ship，Plane，让他们各自负责陆地上，水上，空中的交通工具，使其互不影响。

如果我们需要对水上交通做“风级大于8级，禁止出海”的限制，就只需要对Ship类进行修改。

具体代码如下：

single类：

Car类：

Ship类：

Plane类：

运行结果：

我们可以发现单一职责原则有点代码太多了，显得冗余。毕竟我们程序员是能少写就少写，决不能多写代码。那我们对其优化下，上面每个类只有一个方法，我们可以合并为一个类，其中有三个方法，每个方法对应着在公路上，在水上，在天空中的交通工具，将单一职责原则落在方法层面，而不再是类层面，代码如下：

single类：

Vehicle类：

运行结果：

优点：

• 降低类的复杂性，一个类只负责一个职责。
• 提高代码的可读性，逻辑清楚明了。
• 降低风险，只修改一个类，并不影响其他类的功能。

缺点：代码量增多。(可将单一职责原则落在方法层面进行优化)

类不应该依赖他不需要的接口，接口尽量小颗粒划分。

People类：

Student类：

Teacher类：

test类：

运行结果：

注：此处代码并没有报错，正常运行的，但是看得代码冗余且奇怪。Student只需要实现People的exam方法，而Teacher只需要实现People的teach方法，但是现在Student实现了People接口，就必须重写exam和teach方法，Teacher也是如此。

我们将People接口的两个方法拆分开，分为两个接口People1和People2，并且让Sudent实现People1接口，Teacher实现People2接口，使其互不干扰，具体代码如下：

People1类：

People2类：

Student类：

Teacher类：

test类：

运行结果：

言归正传，如果将多个方法合并为一个接口，再提供给其他系统使用的时候，就必须实现该接口的所有方法，那有些方法是根本不需要的，造成使用者的混淆。

高层模块不应该依赖底层模块，二者都应该依赖接口或抽象类。

其核心就是面向接口编程。

依赖倒转原则主要基于如下的设计理念：相对于细节的多变性，抽象的东西要稳定的多，以抽象为基础搭建的架构比以细节为基础的架构要稳定的多。

抽象指接口或抽象类，细节指具体的实现类。

这样讲太干涩，照搬宣科，没有灵魂，说了等于没说。接下来我们用例子来说明。

由于现在是特殊时期，我们先来一个买菜的例子。如下是傻白甜的例子，未使用到依赖倒转原则。

Qingcai类：

People类：

test类：

运行结果：

上述看着没啥问题，但是如果他不想买青菜，想买萝卜怎么办？我们当然可以新建一个萝卜类，再给他弄一个run方法，但是问题是People并没有操作萝卜类的方法，我们还需要在People添加对萝卜类的依赖。这样代码要修改的代码量太多了，模块与模块之间的耦合性太高，只要需要稍微有点变化，就要大面积重构，所以该设计不合理，我们看下其类图，如下：

这种设计是一般设计的思考方式，而依赖倒转原则中的倒转是指和平常的思考方式完全相反，先从底部开始，即先从Qingcai和Luobo开始，然后想是否能抽象出什么。很明显，他们都是蔬菜，然后我们再回头重新思考如何来设计，新的设计图如下：

（请原谅我手残党，画图都画不好。。。）

我们可以看到将低层的类抽象出一个接口Shucai，其直接和高层进行交互，而低层的一些类则不参与，这样能降低代码的耦合性，提高稳定性。

思路有了，那就来代码耍耍把。

Shucai类：

Qingcai类：

Luobo类：

People类：

test类：

运行结果：

该原则重点在“倒转”，要从低层往上思考，尽量抽象抽象类和接口。此例子很好的解释了“上层模块不应该依赖低层模块，他们都应该依赖于抽象”。在最开始的设计中，上层模块依赖了低层模块，调整后，上层模块和低层模块都依赖于接口Shucai，依赖关系从图中可以看出来了“倒转”。

里氏替换原则是1988年麻省理工姓李的女士提出，它是阐述了对继承extends的一些看法。

继承的优点：

1. 提高代码的重用性，子类也有父类的属性和方法。
2. 提高代码的可扩展性，子类有自己特有的方法。

继承的缺点：

当父类发生改变的时候，要考虑子类的修改。

里氏替换原则是继承的基础，只有当子类替换父类时，软件功能仍然不受到影响，才说明父类真正被复用啦。

子类必须实现父类的抽象方法，但不得重写（覆盖）父类的非抽象（已实现）方法。

反例

父类A：

子类B：

测试类test:

运行结果：

注：我每次使用子类替换父类的时候，还要担心这个子类有没有可能导致问题。此处子类不能直接替换成父类，故没有遵循里氏替换原则。

子类中可以增加自己特有的方法

父类A:

子类B：

测试类test：

运行结果：

注：父类A 有run方法，继承父类A的子类B有runOwn方法，测试类test先是调用A类的run方法，接着用B类替换A类，发现还是执行的是父类A的run方法，最后再调用子类B特有的方法runOwn方法。如上，说明该段代码已使用了里氏替换原则。

当子类覆盖或实现父类的方法时，方法的前置条件（即方法的形参）要比父类方法的输入参数更宽松。

父类A：

子类B :

测试类test：

运行结果：

我们可以看到在测试类test中，将父类A替换成子类B的时候，还是显示的执行结果“父类执行”，我们可以发现他并不是重写，而是方法重载，因为参数不一样，所以他其实是对继承的规范化，为了更好的使用继承。关于是否为方法重载或重写，我们从下图看：

如果是重写，在上图标红的位置会出现箭头，我们可以看出是实际为重载。

那如果没有使用这个规则，会是什么样？看下面的代码：

父类A：

子类B：

测试test:

运行结果：

我们可以看到将子类的范围比父类大的时候，替换的子类还是执行自己的子类方法。此不符合里氏替换原则。

我们平常好像也没有遵循这些里氏替换原则，程序还是正常跑。其实如果不遵循里氏替换原则，你写的代码出问题的几率会大大增加。

前面四个原则，单一职责原则，接口屏蔽原则，依赖倒转原则，里氏替换原则可以说都是为了开闭原则做铺垫，其是编程汇总最基础，最重要的设计原则，核心为对扩展开发，对修改关闭，简单来说，通过扩展软件的行为来实现变化，而不是通过修改来实现，尽量不修改代码，而是扩展代码。

接口transport：

Bus:

当我们修改需求，让大巴也能有在水里开的属性，我们可以对Bus类添加一个方法即可。但是这个已经违背了开闭原则，如果业务复杂，这样子的修改很容易出问题的。

我们可以新增一个类，实现transport接口，并继承Bus类，写自己的需求即可。

1. 一个对象应该对其他对象保持最少的了解。
2. 类与类关系越密切，耦合度越大
3. 一个类对自己依赖的类知道的越少越好。也就是说，对于被依赖的类不管多么复杂，都尽量将逻辑封装在类的内部。对外除了提供的public 方法，不对外泄露任何信息
4. 迪米特法则还有个更简单的定义：只与直接（熟悉）的朋友通信
5. 直接（熟悉）的朋友：每个对象都会与其他对象有耦合关系，只要两个对象之间有耦合关系， 我们就说这两个对象之间是朋友关系。耦合的方式很多，依赖，关联，组合，聚合等。其中，我们称出现成员变量，方法参数，方法返回值中的类为直接的朋友，而出现在局部变量中的类不是直接的朋友。也就是说，陌生的类最好不要以局部变量 的形式出现在类的内部。

把上面的概念一一翻译成人话就是：

1. 我们这个类姑娘啊，因为太矜持了不善于社交，所以对其他类伙伴们不怎么熟悉。
2. 类姑娘实在是太害羞了，一旦与别人多说几句话就会紧张的不知所措，频频犯错。
3. 矜持的类姑娘尽管心思很活跃，爱多想。但是给别人的感觉都是纯洁的像一张白纸。
4. 因为类姑娘太过于矜持，害怕陌生人，认为陌生人都是坏人，所以只与自己熟悉的朋友交流。
5. 类姑娘熟悉的朋友有：成员变量，方法参数，方法返回值的对象。而出现在其他地方的类都是陌生人，坏人！本姑娘拒绝与你交流！！！

哈哈，这样应该大家都能理解了。总而言之就一句话：一个类应该尽量不要知道其他类太多的东西，不要和陌生的类有太多接触。

总公司员工Employee类：

分公司员工SubEmployee类：

总公司员工管理EmployeeManager类：

分公司员工管理SubEmployeeManager类：

测试类：

运行结果：

上面的代码是正常运行的，但是可以看到一个问题，EmployeeManager类的printAllEmployee方法中使用的局部变量SubEmployee是不符合迪米特法则的，其是陌生朋友，应该拒绝沟通。

EmployeeManager类:

SubEmployeeManager类：

我们将EmployeeManager类printAllEmployee方法中的打印分公司的代码移到了分公司的管理类SubEmployeeManager类中，再在方法中显示的调用SubEmployeeManager类的方法，这符合迪米特法则的。

尽量使用合成/集合，不要用继承。

如果使用继承，会使得耦合性加强，尽量作为方法的输入参数或类的成员变量，这样可以避免耦合。

所有的原则只是规范，为了代码更加优雅，为了让人一目了然。如果一定不遵循原则，那代码还是可以跑的，只是日后出bug的可能性提高。

以上，简单来说，主要包括两点：

1.找出应用中需要变化的独立出来，不要和固定的混合在一起。

2.面向接口编程，而不是面向实现编程

作者：学习Java的小姐姐

原文链接：https://juejin.im/post/5e48c979e51d4526ee0f7301

专门画了9张图，搞懂设计模式6大原则，这次应该可以了吧

设计模式（Design pattern）是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。 毫无疑问，设计模式于己于他人于系统都是多赢的；设计模式使代码编制真正工程化；设计模式是软件工程的基石脉络，如同大厦的结构一样。

借用并改编一下鲁迅老师《故乡》中的一句话，一句话概括设计模式: 希望本无所谓有，无所谓无．这正如coding的设计模式，其实coding本没有设计模式，用的人多了，也便成了设计模式

读者福利：关注小编+私信回复【项目】获取整理好的100+个Java项目视频+源码+笔记

1.开闭原则（Open Closed Principle，OCP）

2.里氏代换原则（Liskov Substitution Principle，LSP）

3.依赖倒转原则（Dependency Inversion Principle，DIP）

4.接口隔离原则（Interface Segregation Principle，ISP）

5.合成/聚合复用原则（Composite/Aggregate Reuse Principle，CARP）

6.最小知识原则（Principle of Least Knowledge，PLK，也叫迪米特法则）

开闭原则具有理想主义的色彩，它是面向对象设计的终极目标。其他几条，则可以看做是开闭原则的实现方法。 设计模式就是实现了这些原则，从而达到了代码复用、增加可维护性的目的。

1.概念：

一个软件实体如类、模块和函数应该对扩展开放，对修改关闭。模块应尽量在不修改原（是“原”，指原来的代码）代码的情况下进行扩展。

2.模拟场景：

在软件的生命周期内，因为变化、升级和维护等原因需要对软件原有代码进行修改时，可能会给旧代码中引入错误，也可能会使我们不得不对整个功能进行重构，并且需要原有代码经过重新测试。

3.Solution：

当软件需要变化时，尽量通过扩展软件实体的行为来实现变化，而不是通过修改已有的代码来实现变化。

4.注意事项：

通过接口或者抽象类约束扩展，对扩展进行边界限定，不允许出现在接口或抽象类中不存在的public方法

参数类型、引用对象尽量使用接口或者抽象类，而不是实现类

抽象层尽量保持稳定，一旦确定即不允许修改

5.开闭原则的优点：

可复用性

可维护性

6.开闭原则图解：

1.概述：

派生类(子类)对象能够替换其基类(父类)对象被调用

2.概念：

里氏代换原则(Liskov Substitution Principle LSP)面向对象设计的基本原则之一。 里氏代换原则中说，任何基类可以出现的地方，子类一定可以出现。 LSP是继承复用的基石，只有当衍生类可以替换掉基类，软件单位的功能不受到影响时，基类才能真正被复用，而衍生类也能够在基类的基础上增加新的行为。里氏代换原则是对“开-闭”原则的补充。实现“开-闭”原则的关键步骤就是抽象化。而基类与子类的继承关系就是抽象化的具体实现，所以里氏代换原则是对实现抽象化的具体步骤的规范。(源自百度百科)

3.子类为什么可以替换父类的位置？：

当满足继承的时候，父类肯定存在非私有成员，子类肯定是得到了父类的这些非私有成员（假设，父类的的成员全部是私有的，那么子类没办法从父类继承任何成员，也就不存在继承的概念了）。既然子类继承了父类的这些非私有成员，那么父类对象也就可以在子类对象中调用这些非私有成员。所以，子类对象可以替换父类对象的位置。

4.里氏代换原则优点：

需求变化时，只须继承，而别的东西不会改变。由于里氏代换原则才使得开放封闭成为可能。这样使得子类在父类无需修改的话就可以扩展。

5.里氏代换原则Demo：

代码正文：

代码效果：

6.里氏代换原则图解：

1.概念：

依赖倒置原则（Dependence Inversion Principle）是程序要依赖于抽象接口，不要依赖于具体实现。简单的说就是要求对抽象进行编程，不要对实现进行编程，这样就降低了客户与实现模块间的耦合。

2.依赖倒转原则用处：

有些时候为了代码复用，一般会把常用的代码写成函数或类库。这样开发新项目时，直接用就行了。比如做项目时大多要访问数据库，所以我们就把访问数据库的代码写成了函数。每次做项目去调用这些函数。那么我们的问题来了。我们要做新项目时，发现业务逻辑的高层模块都是一样的，但客户却希望使用不同的数据库或存储住处方式，这时就出现麻烦了。我们希望能再次利用这些高层模块，但高层模块都是与低层的访问数据库绑定在一起，没办法复用这些高层模块。所以不管是高层模块和低层模块都应该依赖于抽象，具体一点就是接口或抽象类，只要接口是稳定的，那么任何一个更改都不用担心了。

3.注意事项：

• 高层模块不应该依赖低层模块。两个都应该依赖抽象。
• 抽象不应该依赖细节。细节应该依赖抽象。

4.模拟场景：

场景：

假设现在需要一个Monitor工具，去运行一些已有的APP，自动化来完成我们的工作。Monitor工具需要启动这些已有的APP，并且写下Log。

代码实现1：

代码解析1：

在代码实现1中我们已经轻松实现了Monitor去运行已有APP并且写下LOG的需求。并且代码已经上线了.

春…夏…秋…冬…

春…夏…秋…冬…

春…夏…秋…冬…

就这样，三年过去了。

一天客户找上门了，公司业务扩展了，现在需要新加3个APP用Monitor自动化。这样我们就必须得改Monitor。

代码实现2：

代码解析2：

这样会给系统添加新的相互依赖。并且随着时间和需求的推移，会有更多的APP需要用Monitor来监测，这个Monitor工具也会被越来越对的if…else撑爆炸，而且代码随着APP越多，越难维护。最终会导致Monitor走向灭亡(下线)。

介于这种情况，可以用Monitor这个模块来生成其它的程序，使得系统能够用在需要的APP上。OOD给我们提供了一种机制来实现这种“依赖倒置”。

代码实现3：

代码解析3：

现在Monitor依赖于IApp这个接口，而与具体实现的APP类没有关系，所以无论再怎么添加APP都不会影响到Monitor本身，只需要去添加一个实现IApp接口的APP类就可以了。

1.概念：

客户端不应该依赖它不需要的接口，类间的依赖关系应该建立在最小的接口上

2.含义：

接口隔离原则的核心定义，不出现臃肿的接口（Fat Interface），但是“小”是有限度的，首先就是不能违反单一职责原则。

3.模拟场景：

一个OA系统，外部只负责提交和撤回工作流，内部负责审核和驳回工作流。

4.代码演示：

5.代码解析：

其实接口隔离原则很好理解，在上面的例子里可以看出来，如果把OA的外部和内部都定义一个接口的话，那这个接口会很大，而且实现接口的类也会变得臃肿。

1.概念：

合成/聚合复用原则（Composite/Aggregate Reuse Principle，CARP）经常又叫做合成复用原则。合成/聚合复用原则就是在一个新的对象里面使用一些已有的对象，使之成为新对象的一部分；新的对象通过向这些对象的委派达到复用已有功能的目的。它的设计原则是：要尽量使用合成/聚合，尽量不要使用继承。

2.合成/聚合解析：

• 聚合概念： 聚合用来表示“拥有”关系或者整体与部分的关系。代表部分的对象有可能会被多个代表整体的对象所共享，而且不一定会随着某个代表整体的对象被销毁或破坏而被销毁或破坏，部分的生命周期可以超越整体。例如，Iphone5和IOS，当Iphone5删除后，IOS还能存在，IOS可以被Iphone6引用。
• 聚合关系UML类图：

• 代码演示：

• 合成概念：

合成用来表示一种强得多的“拥有”关系。在一个合成关系里，部分和整体的生命周期是一样的。一个合成的新对象完全拥有对其组成部分的支配权，包括它们的创建和湮灭等。使用程序语言的术语来说，合成而成的新对象对组成部分的内存分配、内存释放有绝对的责任。一个合成关系中的成分对象是不能与另一个合成关系共享的。一个成分对象在同一个时间内只能属于一个合成关系。如果一个合成关系湮灭了，那么所有的成分对象要么自己湮灭所有的成分对象（这种情况较为普遍）要么就得将这一责任交给别人（较为罕见）。例如：水和鱼的关系，当水没了，鱼也不可能独立存在。

合成关系UML类图：

代码演示：

3.模拟场景：

比如说我们先摇到号(这个比较困难)了，需要为自己买一辆车，如果4S店里的车默认的配置都是一样的。那么我们只要买车就会有这些配置，这时使用了继承关系：

不可能所有汽车的配置都是一样的，所以就有SUV和小轿车两种(只列举两种比较热门的车型)，并且使用机动车对它们进行聚合使用。这时采用了合成/聚合的原则：

1.概念：

一个软件实体应当尽可能少的与其他实体发生相互作用。每一个软件单位对其他的单位都只有最少的知识，而且局限于那些与本单位密切相关的软件单位。迪米特法则的初衷在于降低类之间的耦合。由于每个类尽量减少对其他类的依赖，因此，很容易使得系统的功能模块功能独立，相互之间不存在（或很少有）依赖关系。迪米特法则不希望类之间建立直接的联系。如果真的有需要建立联系，也希望能通过它的友元类来转达。因此，应用迪米特法则有可能造成的一个后果就是：系统中存在大量的中介类，这些类之所以存在完全是为了传递类之间的相互调用关系——这在一定程度上增加了系统的复杂度。

2.模拟场景：

场景：公司财务总监发出指令，让财务部门的人去统计公司已发公司的人数。

一个常态的编程:（肯定是不符LoD的反例）

UML类图:

代码演示:

根据模拟的场景：财务总监让财务部门总结已发工资的人数。 财务总监和员工是陌生关系(即总监不需要对员工执行任何操作)。根据上述UML图和代码解决办法显然可以看出，上述做法违背了LoD法则。

依据LoD法则解耦:（符合LoD的例子）

UML类图:

代码演示:

根据LoD原则我们需要让财务总监和员工之间没有之间的联系。这样才是遵守了迪米特法则。

想搞懂设计模式，必须先知道设计模式遵循的六大原则，无论是哪种设计模式都会遵循一种或者多种原则。这是面向对象不变的法则。本文针对的是设计模式(面向对象)主要的六大原则展开的讲解，并尽量做到结合实例和UML类图，帮助大家理解。在后续的博文中还会跟进一些设计模式的实例。

作者：请叫我头头哥

原文：www.cnblogs.com/toutou

本文作者及来源:Renderbus瑞云渲染农场https://www.renderbus.com