软件设计六大原则分别是：
开闭原则
依赖倒置原则
接口隔离原则
迪米特(最少知道)原则
里式替换原则
单一职责原则。
三个需要我们避免的不好的设计：
1.可维护性差 - 很难修改因为每次修改影响到系统其它部分做太多的修改.
2不健壮 – 当你做个修改, 系统某个木有想到的部分崩溃了.
3不可移植性- 很难在另外一个系统重用因为它不能从当前应用分离出来.
开闭原则：
软件实体例如类 , 模块和函数应该 对 扩展 开放 但是 对 修改封闭。
OPC 是一个基本原则. 你可以考虑使用该原则当你编写类时确保当你扩展它们行为时:你不需要修改
类而是扩展它. 相同的原则适用于模块,包, 类库. 如果你有一个包含多个类的类库,有很多原因导致
最好扩展它而不需要修改已经编写的代码(向后兼容, 回归测试). 这就是为什么我们不得不确保我们
的模块遵循开闭原则的原因.
当我们对类应用开闭原则，我们可以通过使用抽象类和具体类来实现它们的行为. 这将确保具体类继
承抽象类而不是修改它们. 一些特殊场景可以使用模板模式和策略模式.
依赖倒置原则：
1.高层模块不应该依赖底层模块 . 两者都应该依赖抽象 .
2. 抽象不应该依赖具体 . 具体应该依赖抽象 .
依赖倒置原则强调我们应该把高层模块从底层模块解耦, 引入一个抽象层在高层类和底层类之间.
进一步翻译该原则: 不是编写抽象基于具体, 我们应该基于抽象编写具体代码.
依赖倒置或者控制反转是著名的依赖倒置实现. 在经典方式 当一个软件模块 (类, 框架) 需要其它模块, 它初始化其它模块并对之有一个直接引用. 这将导致两个模块紧密耦合. 为了解耦和第一个模块应该提供一个钩子 (属性,参数)且由一个外部模块控制依赖,该外部模块注入依赖对象.
通过应用依赖倒置 ,模块可以容易修改通过修改依赖模块. 工厂和抽象工厂可以作为依赖框架, 但由
专门的框架来完成该任务,称之为控制反转容器.（spring框架）
接口隔离原则：
客户不应该被强制依赖它们不使用的接口 .
该原则教我们如何编写接口. 当我们编写接口我们应该十分小心添加应该出现该接口的方法. 如果我们添加类不需要实现的方法在接口,那么我们类也不得不实现它. 例如如果我们创建一个接口
Worker 并添加一个午间休息方法, 所有 workers 将不得不实现它.但是如果 worker 是一个机器人呢?
作为结论接口应该定义不需要的方法这称为污染或者胖接口.我们应该避免它们.
单一职责原则：
一个类应该仅有一个原因要修改 .
在这种语境下,职责被认为是做出修改的一个原因. 该原则强调如果我们有两个原因修改一个类, 我们需要分割功能到两个类. 每个类应该处理一个职责并且在将来 如果我们需要做出一个修改,我们应该在负责该修改的类中进行. 当我们需要修改一个类让它有更多责任,该修改可能会影响到类的其它功能.
单一职责原则由 Tom DeMarco 在书 Structured Analysis and Systems Specification, 1979介绍. Robert Martin 重新解释该概念并定义了职责是做出修改的一个原因.
里氏替换原则：
派生类必须能够完全替代它们的基类 .
这原则就是开闭原则的一个扩展,该词汇表达我们确保新派生类继承基类而不需要修改它们行为. 新派生类应该能够替换基类而不需要修改代码.
李氏替换原则由 Barbara Liskov 在 1987 Conference on Object Oriented Programming Systems Languages and Applications 提出
迪米特法则：
定义：一个对象应该对其他对象保持最少的了解。
问题由来：类与类之间的关系越密切，耦合度越大，当一个类发生改变时，对另一个类的影响也越大。
解决方案：尽量降低类与类之间的耦合。
自从我们接触编程开始，就知道了软件编程的总的原则：低耦合，高内聚。无论是面向过程编程还是面向对象编程，只有使各个模块之间的耦合尽量的低，才能提高代码的复用率。低耦合的优点不言而喻，但是怎么样编程才能做到低耦合呢？那正是迪米特法则要去完成的。
迪米特法则又叫最少知道原则，最早是在1987年由美国Northeastern University的Ian Holland提出。通俗的来讲，就是一个类对自己依赖的类知道的越少越好。也就是说，对于被依赖的类来说，无论逻辑多么复杂，都尽量地的将逻辑封装在类的内部，对外除了提供的public方法，不对外泄漏任何信息。迪米特法则还有一个更简单的定义：只与直接的朋友通信。首先来解释一下什么是直接的朋友：每个对象都会与其他对象有耦合关系，只要两个对象之间有耦合关系，我们就说这两个对象之间是朋友关系。耦合的方式很多，依赖、关联、组合、聚合等。其中，我们称出现成员变量、方法参数、方法返回值中的类为直接的朋友，而出现在局部变量中的类则不是直接的朋友。也就是说，陌生的类最好不要作为局部变量的形式出现在类的内部。
