1.基本介绍1.1.概念高层模块不能依赖于一个“具体化、细节化”的低层模块，而是通过一个抽象的“规范/标准”建立两者之间的依赖关系，简言之就是：不依赖于实现，而是依赖于抽象。这里“实现”一词有的地方也称为“细节”，在编码中主要体现的是我们根据业务模型具体自定义的普通类，比如：员工类、商品类等。而其中的“抽象”一词是指定的接口或抽象类。 1.2.高层与低层下面我们通过传统的三层架构作为背景来理解“依赖倒置原则”中的高层与低层的含义。在分层架构中，高层是相对而言的，对于上面三层架构图中而言最高层是“表示层”，相对于“业务逻辑层”它的高层是“表示层UI”，相对于“数据访问层”它的高层则是“业务逻辑层
1.基本介绍1.1.概念高层模块不能依赖于一个“具体化、细节化”的低层模块，而是通过一个抽象的“规范/标准”建立两者之间的依赖关系，简言之就是：不依赖于实现，而是依赖于抽象。这里“实现”一词有的地方也称为“细节”，在编码中主要体现的是我们根据业务模型具体自定义的普通类，比如：员工类、商品类等。而其中的“抽象”一词是指定的接口或抽象类。 1.2.高层与低层下面我们通过传统的三层架构作为背景来理解“依赖倒置原则”中的高层与低层的含义。在分层架构中，高层是相对而言的，对于上面三层架构图中而言最高层是“表示层”，相对于“业务逻辑层”它的高层是“表示层UI”，相对于“数据访问层”它的高层则是“业务逻辑层
重要性有过一些实际开发工作的朋友一定对某个场景会深有体会，那就是客户经常会对现有的功能提出新的需求要我们改动，并且要快速完成。如果你的代码没有很好的遵循“开闭原则”，并且顶着工期的缩减，那我们对需求变化的修改，“往往就像在一个草稿纸上反复的涂抹”，随着不断的变化修改代码就会显得很乱，可能到最后你连自己的代码都看不懂了，还可能影响现有的功能（“赔了夫人又折兵”） 定义开闭原则在定义描述上其实非常的简短，那就是：“对扩展开放，对修改关闭”，该原则是编程种最基本、最重要的设计原则。其实在经过实际的开发工作后，大家都自然而然的会体会到这个开闭原则的思想：就是我们在对现有功能进行调整修改的时候，我们的调
重要性有过一些实际开发工作的朋友一定对某个场景会深有体会，那就是客户经常会对现有的功能提出新的需求要我们改动，并且要快速完成。如果你的代码没有很好的遵循“开闭原则”，并且顶着工期的缩减，那我们对需求变化的修改，“往往就像在一个草稿纸上反复的涂抹”，随着不断的变化修改代码就会显得很乱，可能到最后你连自己的代码都看不懂了，还可能影响现有的功能（“赔了夫人又折兵”） 定义开闭原则在定义描述上其实非常的简短，那就是：“对扩展开放，对修改关闭”，该原则是编程种最基本、最重要的设计原则。其实在经过实际的开发工作后，大家都自然而然的会体会到这个开闭原则的思想：就是我们在对现有功能进行调整修改的时候，我们的调
背景在我们日常工作中，代码写着写着就出现下列的一些臭味。但是还好我们有SOLID这把‘尺子’,可以拿着它不断去衡量我们写的代码，除去代码臭味。这就是我们要学习SOLID原则的原因所在。设计的臭味僵化性具有联动性，动一处，会牵连到其他地方脆弱性不敢改动，动一处，全局瘫痪顽固性不易改动粘滞性耦合性太高不必要的复杂性代码设计过于复杂不必要的重复提高复用性，减少重复晦涩性代码设计不易理解SRP-单一职责原则一个类只做一件事情。当然一件事情，不是说类中只有一个方法。而是类中的方法都是属于同一种职责。不能因为第二职责的原因去改动这个类。一个很好的例子：在我们封装request库时，我们需要实现以下4个方法
背景在我们日常工作中，代码写着写着就出现下列的一些臭味。但是还好我们有SOLID这把‘尺子’,可以拿着它不断去衡量我们写的代码，除去代码臭味。这就是我们要学习SOLID原则的原因所在。设计的臭味僵化性具有联动性，动一处，会牵连到其他地方脆弱性不敢改动，动一处，全局瘫痪顽固性不易改动粘滞性耦合性太高不必要的复杂性代码设计过于复杂不必要的重复提高复用性，减少重复晦涩性代码设计不易理解SRP-单一职责原则一个类只做一件事情。当然一件事情，不是说类中只有一个方法。而是类中的方法都是属于同一种职责。不能因为第二职责的原因去改动这个类。一个很好的例子：在我们封装request库时，我们需要实现以下4个方法
1.概念1.1.知道的越少越好迪米特法则，结合其含义又称之为“最少知道原则”，即一个类作为一个调用方，应当对自己依赖的类(被调用的类)其中所处理的逻辑细节，知道的越少越好。对于被依赖的类(被调用的类)不管在使用上多么的复杂，它都应尽量将处理逻辑封装在它的内部，对调用方提供简洁明了的公共方法即可，以此减轻上层调用方过多承担复杂逻辑的压力和变化。1.2.朋友和陌生人对于程序编码设计是否遵循了“迪米特法则”，我们通常可以使用一段经典的描述来判断，该描述是：“只和朋友通信，不和陌生人说话”。那么对于这段话中什么是朋友，什么是陌生人，下面对其进行一个介绍。每个对象都会与其他对象之间都存在一定程度的耦合关
1.概念1.1.知道的越少越好迪米特法则，结合其含义又称之为“最少知道原则”，即一个类作为一个调用方，应当对自己依赖的类(被调用的类)其中所处理的逻辑细节，知道的越少越好。对于被依赖的类(被调用的类)不管在使用上多么的复杂，它都应尽量将处理逻辑封装在它的内部，对调用方提供简洁明了的公共方法即可，以此减轻上层调用方过多承担复杂逻辑的压力和变化。1.2.朋友和陌生人对于程序编码设计是否遵循了“迪米特法则”，我们通常可以使用一段经典的描述来判断，该描述是：“只和朋友通信，不和陌生人说话”。那么对于这段话中什么是朋友，什么是陌生人，下面对其进行一个介绍。每个对象都会与其他对象之间都存在一定程度的耦合关
每一个模式描述了一个在我们周围不断重复发生的问题，以及该问题的解决方案的核心。这样，你就能一次又一次的使用该方案而不必重复劳动。 ——ChristoperAlexander 设计原则是评判设计模式的一把标尺。 1.依赖倒置原则（DIP）高层模块（稳定）不应该依赖于底层模块（变化），二者都是都应该依赖于抽象（稳定）。抽象（稳定）不应该依赖于实现细节（变化），实现细节应该依赖于抽象。 2.开放封闭原则（OCP）对扩展开放，对更改封闭类模块应该是可扩展的，但是不可修改 3.单一职责原则（SRP）一个类应该仅有一个引起它变化的原因变化的方向隐含着类的责任（bridge模式，decor
每一个模式描述了一个在我们周围不断重复发生的问题，以及该问题的解决方案的核心。这样，你就能一次又一次的使用该方案而不必重复劳动。 ——ChristoperAlexander 设计原则是评判设计模式的一把标尺。 1.依赖倒置原则（DIP）高层模块（稳定）不应该依赖于底层模块（变化），二者都是都应该依赖于抽象（稳定）。抽象（稳定）不应该依赖于实现细节（变化），实现细节应该依赖于抽象。 2.开放封闭原则（OCP）对扩展开放，对更改封闭类模块应该是可扩展的，但是不可修改 3.单一职责原则（SRP）一个类应该仅有一个引起它变化的原因变化的方向隐含着类的责任（bridge模式，decor
