weixin_43771403的博客

开放-关闭原则 (Open-Closed Principle)定义：软件实体（类、模块、函数等等）应该是可以扩展的，但是不可以修改的对于扩展是开放的：模块行为是可以扩展的，当应用需求改变时，我们可以对模块进行扩展，使其满足那些改变的行为。对于修改是封闭的：对模块扩展时，不必改动模块的源代码如下图：Computer 类有一个生产电脑 productComputer() 的方法；MacBook 类和 Dell 类都要调用 productComputer() 方法，传入电脑类型 type 来生产电脑；

单一职责原则 (Single Responsibility Principle)定义： 就一个类而言，应该仅有一个引起它变化的原因（通俗说：一个类只负责一项职责）为什么需要单一职责呢？如果一个类承担的职责过多，就等于把这些职责耦合在一起了，一个职责的变化可能会引起其它职责的变化，当变化发生时，设计会遭到意想不到的变化。如下图：Member 类有俩方法，一个是获取会员等级 getLevel() ，一个是计算会员折扣 discount()，Order 类要调用 getLevel() 和 discount

里氏替换原则 (Liskov Substitution Principle)定义：派生类（子类）对象可以在程序中代替其基类（超类）对象简单的理解为一个软件实体如果使用的是一个父类，那么一定适用于其子类，而且它察觉不出父类对象和子类对象的区别。也就是说，软件里面，把父类都替换成它的子类，程序的行为没有变化。主要体现在下面四个方面：子类必须实现父类的抽象方法，但不得重写（覆盖）父类的非抽象（已实现）方法。子类中可以增加自己特有的方法。当子类覆盖或实现父类的方法时，方法的前置条件（即方法的形参）

依赖倒转原则 (Dependence Inversion Principle)定义：程序要依赖于抽象接口，不要依赖于具体实现。简单的说就是要求对抽象进行编程，不要对实现进行编程，这样就降低了客户与实现模块间的耦合。问题：类A直接依赖类B，假如要将类A改为依赖类C，则必须通过修改类A的代码来达成。这种场景下，类A一般是高层模块，负责复杂的业务逻辑；类B和类C是低层模块，负责基本的原子操作；假如修改类A，会给程序带来不必要的风险解决方案：将类A修改为依赖接口I，类B和类C各自实现接口I，类A通过接

接口隔离原则 (Interface Segregation Principle)定义：要为各个类建立它们需要的专用接口，而不要试图去建立一个很庞大的接口供所有依赖它的类去调用。使用者依赖了那些它们不使用的方法，就面临着这些未使用的方法改变而带来的变更，无意中导致了它们之间的耦合例子： 学生成绩管理系统包含三个模块：输入成绩模块（插入成绩、删除成绩、修改成绩）；统计成绩模块（计算总分、计算平均分）；打印成绩模块（打印成绩信息、査询成绩信息）,代码如下/** * 输入模块接口 */public

迪米特法则 (Law of Demeter)定义：如果两个软件实体无须直接通信，那么就不应当发生直接的相互调用，可以通过第三方转发该调用。其目的是降低类之间的耦合度，提高模块的相对独立性。迪米特法则（Law of Demeter）又叫作最少知识原则（The Least Knowledge Principle），通俗的来讲，就是一个类对自己依赖的类知道的越少越好。也就是说，对于被依赖的类来说，无论逻辑多么复杂，都尽量地的将逻辑封装在类的内部，对外除了提供的public方法，不对外泄漏任何信息。迪

七大基本原则：单一职责原则、开放-关闭原则、里氏替换原则、依赖倒转原则、接口隔离原则、迪米特法则、组合/聚合复用原则1. 单一职责原则 (Single Responsibility Principle)定义： 就一个类而言，应该仅有一个引起它变化的原因（通俗说：一个类只负责一项职责）为什么需要单一职责呢？如果一个类承担的职责过多，就等于把这些职责耦合在一起了，一个职责的变化可能会引起其它职责的变化，当变化发生时，设计会遭到意想不到的变化。如下图：Member 类有俩方法，一个是获取会员等级 ge

七大设计原则总结归纳：这些原则的目的只有一个：降低对象之间的耦合，增加程序的可复用性、可扩展性和可维护性。