面向对象编程是一种模拟现实的编程范式。问题领域的一些概念，我们会抽象成类；概念的实体，我们会抽象为对象。面向对象的思想已经比较成熟了，前人在使用面向对象编程的过程中已经总结了许多经验，然后记录下来，如：设计模式、OOD、OOP等。下面整理一下，比较大的几个指导原则，深刻理解这些原则一定能做出好的设计，写出漂亮、可维护的代码。或许你已经这么做了，只是还没有意识到而已。
SRP：单一职责原则
SRP（Single Responsibility Principle）：一个类应该仅有一个引起它变化的原因。
漂亮的程序一般都是：高内聚、低耦合。系统应该由许多短小的类组成，每一个类应该只有一个职责。过多的职责会导致臃肿的设计和比较弱的重用性。
遵循单一职责原的优点有：
- 可以降低类的复杂度，一个类只负责一项职责，其逻辑肯定要比负责多项职责简单的多；
- 提高类的可读性，提高系统的可维护性；
- 变更引起的风险降低，变更是必然的，如果单一职责原则遵守的好，当修改一个功能时，可以显著降低对其他功能的影响。
需要说明的一点是单一职责原则不只是面向对象编程思想所特有的，只要是模块化的程序设计，都适用单一职责原则。
OCP：开放封闭原则
OCP（Open Close Principle）：为扩展开放、为修改关闭。
开闭原则（OCP）是面向对象设计中“可复用设计”的基石，是面向对象设计中最重要的原则之一，其它很多的设计原则都是实现开闭原则的一种手段。
1988年，勃兰特·梅耶（Bertrand Meyer）在他的著作《面向对象软件构造（Object Oriented Software Construction）》中提出了开闭原则，它的原文是这样：“Software entities should be open for extension,but closed for modification”。翻译过来就是：“软件实体应当对扩展开放，对修改关闭”。这句话说得略微有点专业，我们把它讲得更通俗一点，也就是：软件系统中包含的各种组件，例如模块（Modules）、类（Classes）以及功能（Functions）等等，应该在不修改现有代码的基础上，引入新功能。开闭原则中“开”，是指对于组件功能的扩展是开放的，是允许对其进行功能扩展的；开闭原则中“闭”，是指对于原有代码的修改是封闭的，即不应该修改原有的代码。
当你在设计一个库的时候，必须考虑这个原则，因为库或一些底层代码，一旦成行几乎不允许做修改。所以必须给使用者留下足够的扩展机制，否则就会被放弃或者被上层使用者随意修改，就有可能破坏设计者的初衷。
DIP：依赖倒置原则
DIP（Dependency Inverse Principle）：逆转高层依赖底层。
所谓依赖倒置原则（Dependence Inversion Principle）就是要依赖于抽象，不要依赖于具体。简单的说就是要求对抽象进行编程，不要对实现进行编程，这样就降低了客户与实现模块间的耦合。
LSP：Liskov替换原则
LSP（Liskov Substitution Principle）：子类可以替换父类并且出现在父类能够出现的地方（面向接口编程）。
里氏代换原则(Liskov Substitution Principle LSP)面向对象设计的基本原则之一。 里氏代换原则中说，任何基类可以出现的地方，子类一定可以出现。 LSP是继承复用的基石，只有当衍生类可以替换掉基类，软件单位的功能不受到影响时，基类才能真正被复用，而衍生类也能够在基类的基础上增加新的行为。里氏代换原则是对“开-闭”原则的补充。实现“开-闭”原则的关键步骤就是抽象化。而基类与子类的继承关系就是抽象化的具体实现，所以里氏代换原则是对实现抽象化的具体步骤的规范。
ISP：接口隔离原则
ISP（Interface Isolation Principle）： 使用多个专门的接口比使用单个接口要好的多。
使用多个专门的接口比使用单一的总接口要好。
一个类对另外一个类的依赖性应当是建立在最小的接口上的。
一个接口代表一个角色，不应当将不同的角色都交给一个接口。没有关系的接口合并在一起，形成一个臃肿的大接口，这是对角色和接口的污染。
“不应该强迫客户依赖于它们不用的方法。接口属于客户，不属于它所在的类层次结构。”这个说得很明白了，再通俗点说，不要强迫客户使用它们不用的方法，如果强迫用户使用它们不使用的方法，那么这些客户就会面临由于这些不使用的方法的改变所带来的改变。
PS. 以上内容，大多都来自网络，编辑整理而来，不标明出处。
