当我走在北京的大马路上，看着一条条的快速路，辅路，潮汐车道，慨叹现代世界的文明，却又不懂这些道路的分流设计。
而我们的面向对象的程序开发，也遵守这样的一些设计准则，才能建设成伟大的罗马，操刀首都和铁岭的城市规划完全是不同的层次，我们的目标是星辰大海。
令狐冲在修炼独孤九剑的时候，剑技纵横天下，而他在习武之初，往往领悟到的是下盘要稳，出拳要快。面向对象的世界也是如此，一系列设计模式的背后，藏着的是面向对象最不可缺少的设计原则，模式外显，原则内藏，程序的世界就可以建立了。
- 开闭原则
- 单一职责原则
- 里氏代换原则
- 依赖倒转原则
- 接口隔离原则
- 合成复用原则
- 最少知识原则（迪米特法则）
1 开闭原则：对扩展开放，对修改关闭。
衡量一个产品在技术上是否优良有一系列标准：高可用、高性能、扩展性强、易伸缩、安全。
这里的扩展性强就是指的开闭原则，即是否可以在现有的体系中扩展出一个新功能来而不修改原来的设计和实现。比如一个汽车包含一个方向盘，我是否可以在不修改这个汽车代码的基础上把这个方向盘修改成车把。当然可以，因为客户喜欢车把。
2 单一职责原则：一个类，一个接口只做一类事情。
我们不可能将一辆汽车的行驶操作中的前进、倒车、左转、右转、还有车的雨刷，车的左转信号、右转信号，以及车的换挡都设计到一个汽车类的方法签名。某一天我手动挡要换自动挡了，如何扩展呢，去继承现有的类重写对应的需求方法么？当然也不失为一种实现，如果需求频繁变化都在最后一次的需求上要更新一点新功能的话，这样的继承体系太过于紊乱，这样的一个汽车类，既做了行驶，还要换挡，还有信号操作，雨刷操作，空调操作，安全保障等。重构上的考虑就是梳理并分解这些继承体系，而在设计上的考虑就是单一职责，即一个类一个接口只做一类事情。
3 里氏代换原则：所有使用基类的地方都能透明的使用子类。
在学习Java之初常常涉及到上转型和下转型的问题，子类的对象指向父类的引用，父类instance of 子类后，可以强制转换对象类型，然后调用子类的一些特有方法。
上转型的优点在于多态，可以随时更换子类的实现。那么这时候要强制性让我们将方法签名抽象到父类中，定义成abstract，那么便有了里氏代换原则，即所有使用基类的地方都能透明的使用子类，强迫我们对系统中的功能和函数进行方法签名的抽象和提取，这样才有的多态。
而所谓的架构师，是根据需求编写出系统的分层和模块，分出服务的提供方和消费方，定义数据的传输，协议等，对系统开发中的边框做出限定，而里氏代换原则的要求就是我们对方法进行抽象，抽象出接口或者抽象方法来，定义方法的功能和输入输出。对于分布式服务来说，架构师做到最精细的地方就是定义接口，形成接口文档，发布。其他开发人员对此进行实现，而架构师愿意做这些么？我们的开发人员其实也能做到这些，架构师也有属于他们更高的追求。
4 依赖倒转：依赖抽象而不依赖实现。
有了抽象，有了里氏代换，才有了多态。这才能够对修改关闭对扩展开放。不多说，各位看官可以自行根据3中的原理结合开发中遇到的设计，自行品味。里氏代换&依赖倒转是面向对象最重要的两个法则，有了这两才有了开闭，进而才能更高层次，更高境界对于软件产品的设计和掌握。
5 接口隔离原则：客户端不应该实现他们那些不需要的接口。
这里的接口并不是指Java语言语法上的Interface接口，而是指更为广义的逻辑上的接口，这个原则要求我们细化接口，用户在使用的时候只需要继承他们需要的接口，不同职责类的接口进行梳理拆分，用户根据需求自己组织。即在接口的设计中要遵从单一职责原则。
6 合成复用原则：多用组合少用继承原则。
解耦，组合委托自然好过于继承这种强制性来的自然。谁爽谁知道。
7 最少知识原则：一个类应当与其他类保持最少的了解。
一个类对其他类保持了解，这种了解包括形参，异常，返回值，成员变量，继承关系，委托等，相关类发生改变的同时，有关联或者继承关系的这些都有或多或少的耦合关系，这种耦合关系越多，一个类受别的类变化受影响的概率也就越大。在遵守最少知识原则的同时，一个类一定是高内聚低耦合的，必然扩展起来要更容易。
其实，面向对象的设计原则并不能以数字来衡量只有七条，模式也并不是说23种就是定数。一切都是由前人的经验归纳出来的，但我们不必拘泥于此。
而面向对象的特征：抽象、继承、封装、多态是否您又有了更深的理解呢？