浅学一下 【设计模式】之 [ 设计原则 ]

浅学一下 【设计模式】

提示：为了个人更好的理解与学习，此系列博客将详细地学习一些设计模式，并加以实现。参考设计来源：https://blog.csdn.net/LoveLion/article/details/17517213

如果你也刚刚开始了解设计模式，那就和我一起吧！

---

---

前言

我们总是能够从一些优秀的项目中观察出一些突出的共性，比如：他们的设计中，总是设计了抽象类一定要设计专门的细节实现类、一个负责的计算的方法绝不会完成多余的打印工作、一般都是设计多个专门的接口而不是使用单一的总接口等等… 哦~ 似乎看出来了一些潜在的规则。没错，在面向对象的系统设计之中，我们总是在追求可维护性和高复用性，这就需要以设计原则为基础来考虑了。这些原则，都是从面向对象的考虑出发，尝试从不同的角度来提升一个软件结果的设计水平。
等我们学习了设计原则就可以去理解、上手一些常用的设计模式。
本节，先通俗的介绍一下一些典型的设计原则。

---

提示：以下是本篇文章正文内容，下面案例可供参考

最常见的有七种面向对象的设计原则，如下所述：

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

这项原则在设计模式之中应用频率非常高，它的定义为：一个软件的实体应该对它的扩展是开放的，但是对其修改是封闭的。
如何理解这句话呢？就是，我们写好一份代码后，总是不会希望在想要添加新功能时，去修改原来的类的代码，而是通过编写新的类来实现新的功能。不过，我们新的类可以通过继承的方式来重用原来的代码。这样，我们总是创建新类来扩展我们的代码的功能与特性，而不是做频繁的修改代码的工作。

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

就是说，我们在所有引用基类对象的地能够透明地使用其派生类的对象。其实，就是基类出现的地方，派生类一定可以出现。此项原则就是对第一条原则的补充，这就是对派生类继承基类的抽象化的规范步骤。

3.依赖倒转原则(Dependence Inversion Principle, DIP)

此项原则要求细节应该依赖于抽象，而抽象不应该依赖于细节。目的就是希望当有新的需求出现时，不应该出现对代码的大规模修改，而是要针对接口编程。

4.单一职责原则(Single Responsibility Principle, SRP)

这个原则很好理解，就是一个类只负责一个功能中的相应职责。浅要来说，就是一个计算的函数中就最好不要出现输出的部分，降低程序的耦合度。

5.合成复用原则(Composite Reuse Principle, CRP)

要求，我们在设计时，尽量使用对象组合，而不是继承来达到复用的目的。也就是在一个新的对象中通过关联关系（组合和聚合）来使用一些已存在的对象，使其成为它的一部分，通过委派调用来调用已有对象的方法，而不把某类的实现暴露给其他类。

6.迪米特法则(Law of Demeter, LoD)

这个原则，定义为一个软件实体应当尽可能少地与其他实体发生相互作用。简单讲，就是降低耦合度，一个类应该与其他类的相关度是较低的，这样当其中一个类发生变化时，其他类受到的影响较小。在此之上，似乎就需要一个“月老”来牵出某两个想要产生“关系”的中间类。由这个中间类来完成一个类对其他类的相关调用。

7.接口隔离原则(Interface Segregation Principle, ISP)

接口隔离原则，即使用多个专门的接口，而不是使用一个单一的总接口然后总是调用它。这样，用户不需要看那些他不关心的接口，总是去找他要用的接口。因此，这就需要我们设计很多个专门实现某功能的小巧的接口，不把大接口封装的极其庞大。

---

总结

浅要理解一下这几个设计原则，下一节就开始进行设计模式的学习…