Lab3漫谈(3)-面向对象编程重要原则汇总

关于Lab3内容涉及到的几个原则汇总

今晚算是有时间来更新博客了，一方面是对Lab3中涉及到的一些知识点重新归纳，对Lab3有个交代，毕竟肝了一周才完成。另一方面考试也临近了，一点点开始复习吧。

---

• 单一功能原则：
  在面向对象编程领域中，单一功能原则（Single responsibility principle）规定每个类都应该有一个单一的功能，并且该功能应该由这个类完全封装起来。所有它的（这个类的）服务都应该严密的和该功能平行（功能平行，意味着没有依赖）。
  保持一个类专注于单一功能点上的一个重要的原因是，它会使得类更加的健壮。
• 开闭原则：
  在面向对象编程领域中，开闭原则规定“软件中的对象（类，模块，函数等等）应该对于扩展是开放的，但是对于修改是封闭的”[1]，这意味着一个实体是允许在不改变它的源代码的前提下变更它的行为。该特性在产品化的环境中是特别有价值的，在这种环境中，改变源代码需要代码审查，单元测试以及诸如此类的用以确保产品使用质量的过程。遵循这种原则的代码在扩展时并不发生改变，因此无需上述的过程。
• Liskov替换原则
  里氏替换原则的内容可以描述为： “派生类（子类）对象可以在程序中代替其基类（超类）对象。”
  
  *接口隔离原则
  接口隔离原则（英语：interface-segregation principles， 缩写：ISP）指明客户（client）应该不依赖于它不使用的方法。[1]接口隔离原则(ISP)拆分非常庞大臃肿的接口成为更小的和更具体的接口，这样客户将会只需要知道他们感兴趣的方法。这种缩小的接口也被称为角色接口（role interfaces）。[2]接口隔离原则(ISP)的目的是系统解开耦合，从而容易重构，更改和重新部署。接口隔离原则是在SOLID (面向对象设计)中五个面向对象设计(OOD)的原则之一，类似于在GRASP (面向对象设计)中的高内聚性。[3]
  *依赖反转原则
  该原则规定：
  1.高层次的模块不应该依赖于低层次的模块，两者都应该依赖于抽象接口。
  2.抽象接口不应该依赖于具体实现。而具体实现则应该依赖于抽象接口。
  迪米特法则
  迪米特法则的初衷在于降低类之间的耦合。由于每个类尽量减少对其他类的依赖，因此，很容易使得系统的功能模块功能独立，相互之间不存在（或很少有）依赖关系。
  迪米特法则不希望类之间建立直接的联系。如果真的有需要建立联系，也希望能通过它的友元类来转达。因此，应用迪米特法则有可能造成的一个后果就是：系统中存在大量的中介类，这些类之所以存在完全是为了传递类之间的相互调用关系——这在一定程度上增加了系统的复杂度。

---

小结

上面给出了六个原则（好像有几个上课只是简单提了一下），以及百科中一些简单的定义等。但实际上理解这些所谓原则，我觉得还是依靠编程经验来的快，初学概念时，完全按照这些原则写出代码我觉得不大可能，甚至会畸形，但是现在写完了几千行代码，当时编写代码的一些考虑，看到这些原则时却会感到不谋而合。
比如说 开闭原则吧，简单说就是为了提高可维护性，在添加或变更功能时，能够不修改源码，课程中提到的方法是通过通用接口来达到效果，当需要新功能的时候，再实现一个接口就行，并不需要大动作去改代码。但仔细想想其实不限于这种方法，比如可以对一些静态方法在设计时就写得更通用（从参数和具体逻辑着手），类也是如此，比如使用泛型。
对于单一功能原则也没什么好说的，功能太复杂的话，怎么让这个实现功能的方法传参呢？传递回去个列表？解析不麻烦嘛？想想就头痛，思维混乱才可能那么瞎写。
Liskov原则，我记得比较清楚的时，老师使用一个父类及其子类来进行一些实例化操作的演示，关键的是父类能有的操作，子类必须有而且可以更好，但是反之，子类有的你父类不一定有，这个感觉写过继承都有这种感觉，实现子类更多的是为了加一些功能什么的吧。
接口隔离原则，印象不是很深，但是看了一下解释，其实和功能单一化原则有异曲同工之处，将庞大臃肿的接口拆分细小的话，实际上也是将职责单一化，效果差不多的。
迪米特法则，这个我觉得可能针对的类指的是功能类，而不是资源类（即用的数据结构），我回想了一下实验中的计划项这个类，对于一个计划清单来说，这个计划项是基本数据结构，比如一个具体的航班计划清单，航班计划是基本数据结构，那么这个航班计划它不是Double类也不是Integer类，我们在构造的时候肯定要写一些很底层的元素类来组装这个数据结构，那就这一点来说，其实耦合度很高的呀，可实际上呢，对于这些高耦合度的底层元素类来说，我们用到的基本都是get和set。那些复杂的功能更强，需求更针对的将会在更高层的类中实现，而这些类的高耦合度才应该是这个法则中提到的问题。

---

就一些概念写了些自己的想法、看法。