设计（收藏几句话，将来用得到）

设计要留后路。如果你的系统是用来在大学里交作业的，演示完就可以拔腿走人，那你就不用搞什么设计了。可是真实的工作中，你搞的东西，总是在不停地被你自己或别人维护，扩展，再利用，再扩展，修改，优化。大牛牛在那里？就是牛在他知道将来的可能变动方向都在哪里。设计要留后路，这个说穿了一钱不值，可做起来就不容易，通常都是在后续开发时搞得焦头烂额，才开始悔恨或抱怨当初的设计。吃了太多苦头的大牛们大发善心，把经验都写出来，告诉你，当系统逻辑有什么需要时，意味着将来可能面对什么样的变动，你最好利用什么样的结构来留一条后路。
http://blog.csdn.net/bboyfeiyu/article/details/50103471
1、优化代码的第一步——单一职责原则
两个完全不一样的功能就不应该放在一个类中。一个类中应该是一组相关性很高的函数、数据的封装。工程师可以不断地审视自己的代码，根据具体的业务、功能对类进行相应的拆分，我想这会是你优化代码迈出的第一步。
2、让程序更稳定、更灵活——开闭原则
对于扩展式开放的，对于修改（错误）是封闭的。
3、构建扩展性更好的系统——里氏替换原则
继承
4、 让项目拥有变化的能力——依赖倒置原则
依赖抽象，而不依赖具体实现。依赖注入。
5、系统有更高的灵活性——接口隔离原则
客户端不应该依赖它不需要的接口。
类间的依赖关系应该建立在最小的接口上。
接口隔离原则的目的是系统解开耦合，从而容易重构、更改和重新部署。
抽象、单一职责、最小化
6、更好的可扩展性——迪米特原则
一个对象应该对其他对象有最少的了解。
迪米特法则还有一个英文解释是：Only talk to your immedate friends，翻译过来就是：只与直接的朋友通信。什么叫做直接的朋友呢？每个对象都必然会与其他对象有耦合关系，两个对象之间的耦合就成为朋友关系，这种关系的类型有很多，例如组合、聚合、依赖等。
在应用开发过程中，最难的不是完成应用的开发工作，而是在后续的升级、维护过程中让应用系统能够拥抱变化。拥抱变化也就意味着在满足需求且不破坏系统稳定性的前提下保持高可扩展性、高内聚、低耦合，在经历了各版本的变更之后依然保持清晰、灵活、稳定的系统架构。当然，这是一个比较理想的情况，但我们必须要朝着这个方向去努力，那么遵循面向对象六大原则就是我们走向灵活软件之路所迈出的第一步。