标签：
A、面向对象的五大基本原则（Object-Oriented Design）
1.单一职责原则（Single Responsibility Principle）：每一个类应该只专注于做一件事。
?一个类应该仅有一个引起它变化的原因(最简单，最容易理解却最不容易做到的一个设计原则)
职员类例子：
比如在职员类里，将工程师、销售人员、销售经理这些情况都放在职员类里考虑，其结果将会非常混乱，在这个假设下，职员类里的每个方法都要if else判断是哪种情况，从类结构上来说将会十分臃肿，并且上述三种的职员类型，不论哪一种发生需求变化，都会改变职员类！这个是大家所不愿意看到的！
2.开闭原则（Open-Closed Principle）：Software entities should be open for extension,but closed for modification
?既开放又封闭，对扩展是开放的，对更改是封闭的！即“在不被修改的前提下被扩展”。
?扩展即扩展现行的模块，当我们软件的实际应用发生改变时，出现新的需求，就需要我们对模块进行扩展，使其能够满足新的需求！
更改封闭即是在我们对模块进行扩展时，勿需对源有程序代码和DLL进行修改或重新编译文件！
这个原则对我们在设计类的时候很有帮助，坚持这个原则就必须尽量考虑接口封装，抽象机制和多态技术！
3.里氏替换原则（Liskov Substitution Principle）：任何基类可以出现的地方，子类一定也可以出现。ITool tool = new Knife();
?子类可以替换父类并且出现在父类能够出现的任何地方
?这个原则也是在贯彻GOF倡导的面向接口编程！在这个原则中父类应尽可能使用接口或者抽象类来实现！
子类通过实现了父类接口，能够替父类的使用地方！通过这个原则，我们客户端在使用父类接口的时候，通过子类实现！意思就是说我们依赖父类接口，在客户端声明一个父类接口，通过其子类来实现，这个时候就要求子类必须能够替换父类所出现的任何地方，这样做的好处就是，在根据新要求扩展父类接口的新子类的时候而不影响当前客户端的使用！
4.依赖倒转原则（Dependency Inversion Principle）：要依赖于抽象，不要依赖于实现。Knife knife = new Knife();knife.slice(); ==> ITool tool = new Knife();tool.slice();
?传统的结构化编程中，最上层的模块通常都要依赖下面的子模块来实现，也称为高层依赖低层！
所以DIP原则就是要逆转这种依赖关系，让高层模块不要依赖低层模块，所以称之为依赖倒置原则！
5.接口隔离原则（Interface Segregation Principle）：
?这个原则的意思是：使用多个专门的接口比使用单个接口要好的多！
这个我有体会，在我实际编程中，为了减少接口的定义，将许多类似的方法都放在一个接口中，最后发现，维护和实现接口的时候花了太多精力，而接口所定义的操作相当于对客户端的一种承诺，这种承诺当然是越少越好，越精练越好，过多的承诺带来的就是你的大量精力和时间去维护！
B、面向对象三大原则：
1．面向对象设计的第一原则：封装变化点。隔离变化点的好处在于，将系统中经常变化的部分和稳定的部分隔离，有助于增加复用性，并降低系统耦合度。很多设计模式的意图中都明显地指出了其对问题的解决方案，学习设计模式的要点是发现其解决方案中封装的变化点。
2．面向对象设计的第二原则：对接口进行编程。这里“接口”的含义表示的程序设计语言中的interface ,或者abstract class。对接口编程的一个好处在于客户端程序并不需要了解具体的实现，而只需要了解接口中声明的方法。更大的好处在于能够使用多态性执行动态性的行为。
Program to an interface,not an implementation
3．面向对象设计的第三原则：多使用组合，而不是继承。Has-a关系要比Is-a关系更好：因为继承是静态行为，也就是编译时行为，这种设计缺乏灵活度，并且具有比组合更高的耦合度；而组合是动态行为，即运行时行为。可以通过使用组合的方式在设计上获得更高的灵活性。GOF设计模式中将设计模式分为对象设计模式和类设计模式，其中对象设计模式居多，原因就在于对象设计模式多使用组合，通过此获得更好的灵活性。
合成/聚合复用原则（Composition/Aggregation Principle）：要尽量使用合成/聚合，而不是继承关系达到复用的目的。
迪米特法则（Law of Demeter）：应当为客户端提供尽可能小的单独的接口，而不要提供大的总接口。
C、接口与类
抽象类是用来继承的
具体类是用来实现的，不是用来继承的
接口仅仅给出方法的特征，而不给出方法的实现，接口比抽象类更加抽象化
因此，接口把方法的特征和方法的实现分割开来：接口常常代表一个角色（role），而实现这个接口的类便是扮演这个角色的演员。一个角色可以由不同的演员来演，而不同的演员之间除了扮演一个共同的角色之外，并不要求有任何其他的共同之处。
class:interface 实现继承(implenmentation inheritance)
class:class 扩展继承(extends inheritance)
在一个类等级结构中的任何一类都可以实现一个接口，这个接口会影响到此类的所有子类，但是不会影响到此类的任何超类。此类将不得不实现这个接口所规定的方法，而其子类则可以从此类自动继承到这些方法，当然也可以选择置换掉所有的这些方法，或者其中的某一些方法。
D、关键词
interface 接口
implementation 实现
inheritance 继承
extends 扩展
encapsulation 封装
composition 组合
robust 健壮
Concrete 具体
Persistence 持久化
E、GOF设计模式
创建型
¤1、系统架构技能之设计模式-单例模式
¤2、系统架构技能之设计模式-工厂模式
3、系统架构技能之设计模式-抽象工厂模式
4、系统架构技能之设计模式-创建者模式
5、系统架构技能之设计模式-原型模式
结构型
1、系统架构技能之设计模式-组合模式
2、系统架构技能之设计模式-外观模式
3、系统架构技能之设计模式-适配器模式
¤4、系统架构技能之设计模式-桥模式
5、系统架构技能之设计模式-装饰模式
¤6、系统架构技能之设计模式-享元模式
7、系统架构技能之设计模式-代理模式
行为型
1、系统架构技能之设计模式-命令模式
¤2、系统架构技能之设计模式-观察者模式
¤3、系统架构技能之设计模式-策略模式
4、系统架构技能之设计模式-职责模式
5、系统架构技能之设计模式-模板模式
6、系统架构技能之设计模式-中介者模式
7、系统架构技能之设计模式-解释器模式
--型
¤迭代器模式
标签：
原文地址：http://blog.csdn.net/zhaoyu16/article/details/51346397
