当应用需求发生改变的时候，我们尽量不要修改源代码，可以对其进行扩展，扩展的功能块不会影响到原来的功能块。
子类可以扩展父类的功能（重写，覆盖），但是尽量不要覆盖父类的方法，这样会使整个体系的可复用性变低；多态运用比较频繁时，容易出现问题。可以通过编写新的方法，来扩充子类的方法。 关于里氏替换原则有一个出名的例子：正方形不是长方形 （企鹅和鸵鸟，虽然属于鸟类，但是他们不会飞，所以也不能成为鸟的子类）
高层的模块不要依赖于低层的模块，抽象不依赖细节，细节应该依赖抽象；面向接口编程，降低程序的耦合性。因为具体的实现具有多变性，但是接口一般来说都是稳定的（持久层）。
一个对象不应该承担太多的职责，也就是不能所有相关的方法都写在一个类里，这样耦合度太高，也就是所谓的类的粒度粗；应当是把必须的或者合适的方法写在一个类中，降低耦合度，提高其内聚性。
和单一职责原则很像，都是为了降低耦合度，提高内聚性。为各个类建立他们需要的专用接口。
《程序员修炼之道》，举个例子：A和B是朋友，B和C是朋友,A和C是陌生的；如果A想让C做一件事情必须先和B进行沟通，B在和C进行沟通，A和C不要直接进行沟通。朋友在这里类似于聚合或者组合这样的关系，可以通过转发来实现，目的也是为了降低耦合度，提高模块之间的独立性。 迪米特法则的弊端：会产生很多的中介类，增加一些系统的复杂性。使用时需要考虑系统架构和结构的清晰性。
类鱼类之间尽量使用组合或者聚合的关系，这样可以提高系统的灵活度和复用性，使用“has a”关系，而不用“is a”关系，继承要遵守里氏替换原则，子类继承了父类的一些特性，尽量不覆盖重写父类方法，这样就失去了代码的灵活性，所以合成复用原则和里氏替换原则是相辅相成的，要思考清楚。
结语：在平时编码中，尽量多的去考虑到OOP的七大原则，在23中设计模式中，可以看出这些原则的重要性，其中开闭原则是最重要的，是其它原则的基础。 笔记中有错别字的地方，还请大家谅解，如有发现，评论区指出，谢谢！！！
