一、面向对象
面向对象，就是将一些属性和行为封装成对象，对于使用者来说不用关心对象的内部具体实现，只管调用它公开的属性方法就行了。同一类型的对象抽象出来就是类。类是对象的模板。
面向对象编程，共三步：
1、设计系统的类和接口；
2、设计类和接口的方法和属性；
3、建立类类和接口之间的关系（继承、实现、依赖、关联（聚合、组合关系））；
类和接口之间的关系请参考：http://www.cnblogs.com/liuling/archive/2013/05/03/classrelation.html
上面三步设计系统，务必按照七大设计原则进行：（以下摘自http://www.cnblogs.com/cavingdeep/archive/2004/10/28/208956.html，红色重点理解）
1) Open-Close Principle（OCP），开-闭原则，讲的是设计对扩展开放，对修改封闭。这是最重要也是最为抽象的原则，基本上我们所说的Reusable Software既是基于此原则而开发的。其他的原则也是对它的实现提供了路径。
2) Liskov Substituition Principle（LSP），里氏代换原则，很严格的原则，规则是“子类必须能够替换基类，否则不应当设计为其子类。”也就是说，子类只能去扩展基类，而不是隐藏或覆盖基类，这个原则在有继承关系时发生作用。如有这方面需要的设计就应当参考以下两种方法替换：
1. 
2.
3) Dependence Inversion Principle（DIP），依赖倒换原则，“设计要依赖于抽象而不是具体化”。这原则是处理依赖关系的，指只依赖于抽象，不依赖于具体类，即程序中所有的依赖关系都应该终止于抽象类或者接口。尽量做到：
1、任何变量都不应该持有一个指向具体类的指针或者引用。
2、任何类都不应该从具体类派生。
3、任何方法都不应该覆写它的任何基类中的已经实现的方法（里氏置换原则为基础）。
4) Interface Segregation Principle（ISP），“将大的接口打散成多个小接口”，从一个客户类的角度来讲：一个类对另外一个类的依赖性应当是建立在最小接口上的。过于臃肿的接口是对接口的污染，不应该强迫客户依赖于它们不用的方法。
5) Composition/Aggregation Reuse Principle（CARP），设计者首先应当考虑组合/聚合，而不是继承（因为它很直观，第一印象就是“哦，这个就是OO啊”）。这个就是所谓的“Favor Composition over Inheritance”，在实践中复合/聚合会带来比继承更大的利益，所以要优先考虑。即高内聚低耦合，组合>聚合>关联>依赖>实现>继承(按耦合关系强弱排序）
6) Law of Demeter or Least Knowlegde Principle（LoD or LKP），迪米特法则或最少知识原则，这个原则首次在Demeter系统中得到正式运用，所以定义为迪米特法则。它讲的是“一个对象应当尽可能少的去了解其他对象”。也就是又一个关于如何松耦合（Loosely-Coupled）的法则。
7) Single-Responsibility Principle(SRP),单一职责原则，就一个类而言，应该只专注于做一件事和仅有一个引起它变化的原因。所谓职责，我们可以理解他为功能，就是设计的这个类功能应该只有一个，而不是两个或更多。
详细介绍优缺点，请参考：http://blog.csdn.net/wangjunkg/article/details/3762132
好了，以上是7大原则（或法则）的介绍，对这些原则的深入研究正是如何得到设计模式的道路。在进行了深入了解后我们就可以开始看看设计模式了，设计模式正是对这些法则的应用，著名的设计模式有四人帮（Gang of Four，GoF）的23个模式，除此之外还有很多其他的一些著名模式，大家可以慢慢研究，如果能自己产出一两个模式的话那就太好了，证明你也是高手了！^_^
设计模式就是前人组织代码的经验总结。上面7这么多原则，都是解决问题的原则，其实彻底一点就是两点：
（1）开闭原则（写的代码支持子类替换，便于升级，那么就要面向抽象编程）
（2）高内聚低耦合（contain内聚关系就是一个人必须要大脑对象，低耦合就是不要把不相关的对象组合在一起）