什么是软件设计原则？

软件设计原则是一组帮助我们避开不良设计的指导方针。这些设计原则是由 Robert Martin 在《敏捷软件开发：原则、模式与实践》一书中整理收集而来。 根据 Robert Martin 的理论，应该避免不良设计的以下三个重要特点：

• 僵化： 很难做改动，因为每一个细微的改动都会影响到系统大量的其他功能

• 脆弱： 每当你做一次改动，总会引起系统中预期之外的部分出现故障
• 死板： 代码很难在其他应用中重用，因其不能从当前应用中单独抽离出来

开放-关闭原则 Open Close Principle

软件实体，如类、模块和函数，应该对扩展开放，对修改关闭。

OPC 是一个通用原则。 你可以在这种情景下考虑此原则：当你构建类的时候，你想要确保以后你要扩展类行为时只需扩展它而不需要修改原类。这原则同样适用于模块、包和代码库。如果你手头一个包含多个类的代码库，大多数情况下你更愿意去扩展它，也不想去修改已有的代码（向后兼容，回归测试等）。 这就是为什么我们必须确保我们的模块遵循开放-关闭原则的原因。
当提及类时，开放-关闭原则可以通过使用抽象类+实现类来实现他们的行为。这会强制使用具体实现类来扩展抽象类而不去修改抽象类。具体的实例有：模版模式、策略模式。

依赖倒置原则 Dependency Inversion Principle

高层次的模块不应该依赖低层次的模块。双方都应该依赖抽象。

抽象不应该依赖具体细节。细节应该依赖抽象。

依赖倒置原则强调：我们应在高低层次的类之间引入一个抽象层来解耦高层次模块和低层次模块。此外，此原则颠倒了依赖关系：它认为我们应该基于抽象来编写具体的实现，而不基于具体实现来编写抽象。
当谈及依赖关系的实现时，我们经常听到的是依赖倒置 (DI) 或者控制反转 (IOC) 。一个软件模块（类，框架等）依赖其他模块时，经典的做法是初始化并持有该模块的直接引用。这种做法导致两个模块的强耦合。为了解耦两者，第一个模块提供一个钩子（一个属性，参数，其他），然后一个专门管理依赖关系的外部模块将第二个模块的引用注入到第一个模块的钩子上。
通过使用依赖倒置原则，只需要修改依赖管理模块，被依赖模块就可以很容易的替换成其他模块。工厂模式和抽象工厂模式可以作为框架管理依赖，不过，有专门的框架来做这件事，称之为控制反转容器（Invertion Of Control Container）。

接口隔离原则Interface Segregation Principle

客户端不应该被强制依赖他们不需要使用的接口

这个原则教导要我们小心对待我们编写的接口。编写接口时，我们必须注意只增加应该在其职责范围内的方法。如果我们增加了不应该出现在接口功能范围内的方法，那么实现此接口的类将不得不实现也那些方法。比如说，我们建了个名为 Worker 的接口，然后增加了个 lunch-break 的方法，那么所有的 Workers 都得实现它。如果有个 Worker 是机器人怎么办？机器人应该不用午休吧。

总而言之，如果一个接口包含了不是针对其意图的方法，那么这个接口就是被污染了或者叫“肥”接口。 应该避免这些非领域内的方法。

单一职责原则 Single Responsibility Principle

一个类，应该只有一个需要进行修改的原因。

关于这点，职责被认为是一个修改的原因。这个原则强调，如果我们基于2个不同的原因去修改一个类，那么我们应该将其功能拆分到2个类中。每个类仅仅负责一个功能。如果日后我需要做一次修改，我们只需修改负责该功能的类就可以了。当我们在同时负责多个功能的类上做一个修改时，可能会影响到其他的功能。
单一职责原则是Tom DeMarco于1979年在他的书《Structure Analysis and System Specification》中提出的。Robert Martin重新解释并将职责(功能)定义为变化的原因。

里氏替换原则 Liskov's Substitution Principle

派生类型必须能被其基类完全代替

此原则是在开放-关闭原则在行为方面的延伸，其意味着我们必须确新的派生类扩展基类的同时不能修改其行为。新创建的派生类应该能够替换基类而不用修改任何代码。
里氏替换原则是 Barbara Liskov 于1987年在 “面向对象编程语言系统和应用程序” 大会上提出的, 具体可看 data abstraction and hiearchy。

如何应用设计原则 摘自《面向对象葵花宝典》

OCP 原则： 总的指导思想

OCP 原则是一个总的指导思想，在面向对象的设计中，如果能够符合 LSP/ISP/DIP 原则，一般情况下就能够符合 OCP 原则了。

除了在面向对象的软件设计中应用外，OCP 也可以用于指导系统架构设计，例如常见的 CORBA、COM 协议，其实可都可以认为是 OCP 原则的具体应用和实现。

SRP 原则： 用于类的设计

当我们想出一个类，或者设计出一个类的原型后，使用 SRP 原则核对类的设计是否符合 SRP 要求。

LSP 原则： 用于指导类继承的设计

当我们设计类之间的继承关系时，使用 LSP 原则来判断这种继承关系是否符合 LSP 要求。

ISP 原则： 用于指导接口的设计

ISP 原则可以认为是　SRP 原则的一个变种，本质上是和 SRP 的思想是一样的。 SRP 用于指导类的设计，而 ISP 用于指导接口的设计

DIP 原则： 用于指导如何抽象

当我们设计类之间的依赖关系时，可以使用 DIP 原则来判断这种依赖是否符合 DIP 原则二。 DIP 原则 和 LSP 原则相辅相成： DIP 原则用于指导抽象出接口或者抽象类，而 LSP 原则用于指导从接口或者抽象类派生出新的子类。

目录： //www.greatytc.com/p/af861220a6cc

jdk中的设计模式： //www.greatytc.com/p/734c62d1fb3d