现在有许多设计原则，但是最基本的，就是SOLID（缩写），这五项原则。
S = 单一责任原则
O = 开闭原则
L = Liscov替换原则
I = 接口隔离原则
D = 依赖倒置原则
1.单一责任原则（SRP 原则）：
它的意思是：“如果你可以在一个设备中实现所有的功能，你却不能这样做”。为什么呢？因为从长远来看它增加了很多的可管理性问题。
从面向对象角度解释是："导致类变化的因素永远不要多于一个。"或者换行个说法："一个类有且只有一个职责"。
如果有多于一个原因会导致你的类改变(或者它的职责多余一个)，你就需要根据其职责把这个类拆分为多个类。
为什么拆分很重要的？
那是因为：
- 每个职责都是轴向变化;
- 如果类包含多个职责，代码会变得耦合;
设计规则如下：
“软件实体（类，模块，函数等）应该对扩展开放，对修改关闭。”
这意味着在最基本的层面上，你可以扩展一个类的行为，而无需修改。这就像我能够穿上衣服，而对我的身体不做任何改变。
扩展开放意味着模块/类的行为可以被扩展,那么当需求变化时我们可以用各种各样的方法制定功能来满足需求变更或者新需求
你要对系统的核心业务进行抽象,如果你抽象化做的比较好,很可能,在扩展功能的时候它们不必做任何改变(比如Server就是一个抽象的概念). 你所定义的抽象的实现 (比如,IIS服务器 实现了 Server) 和 抽象的代码 (Server) 要尽可能的多. 这样在客户端代码中不需要做任何修改就会允许你定义一个新的实现(比如,ApacheServer) .
3.里氏替换原则：（多态性）LSP原则
原则描述了:
"子类型必须能够替换它们的基类."
或者,换句话说:
"使用基类引用的函数必须能够使用派生类而无须了解派生类."
在基本的面向对象原则中,"继承" 通常被描述成 "is a" 的关系. 如果一个 "开发者" 是"软件专业人员",那么 "开发者" 类 应该 继承 "软件开发人员" 类. 这样的 "Is a" 关系在类设计阶段非常重要,但是这也很容易让设计者得意忘形从而以一个糟糕的继承设计告终.
"里氏替换原则" 仅仅是一种确保继承被正确使用的手段.
4.接口隔离原则：
“用户不应该被迫依赖他们不使用的接口。”假如你有一些类，
5.依赖倒置原则：（关键是抽象）
“高层次的模块不应该依赖于低层次的模块，而是，都应该依赖于抽象。”
如果代码不遵循依赖倒置，就有下面的风险：
除 SOLID 原则外还有很多别的面向对象原则。比如：
- “组合替代继承”：是说“用组合比用继承好”;
- “笛米特法则”：是说“类对其它类知道的越少越好”;
- “共同封闭原则”：是说“相关类应该一起打包”;
- “稳定抽象原则”：这是说"类越稳定，就越应该是抽象类";
