1.单一职责原则对于一个类来说，它的变化应该只有一个原因。如果一个类承担了过多的职责，就相当于将这些职责耦合在一起，一个职责的变化可能会削弱或抑制这个类完成其他职责的能力。这种耦合会导致脆弱的设计，当发生变化时会意外中断；很多软件设计的真正意义在于发现职责并将这些职责相互分离。2.开闭原则软件实体应该是可扩展的，但不可修改的。这个原则是面向对象设计的核心，遵循这个原则可以带来面向对象技术所声称的可维护性、可扩展性、可重用性和灵活性。设计者必须选择他设计的模块应该关闭哪些变化，必须首先猜测最有可能发生什么样的变化，然后构造抽象来隔离这些变化。最初编写程序时，假定不会发生更改。当发生变化时，创建抽象以隔离将来发生的类似变化，拒绝不成熟的抽象。第三，Liskov替换原则子类型必须能够替换它们的父类型。由于子类型的可替换性，使用超类型的模块可以在不修改的情况下进行扩展。4.依赖倒置原则高层模块不应该依赖低层模块，两者都应该依赖抽象；抽象不应该依赖于细节，细节应该依赖于抽象。针对接口编程，而不是实现。这个原则可以说是面向对象设计的标志。写的时候考虑的是如何编程抽象而不是细节编程，即程序中所有的依赖都以抽象类或接口来终止。5.Dimit原则（最少知识原则）如果两个类不必直接相互通信，那么这两个类不应该直接交互；如果其中一个类需要调用另一个类的方法，它可以通过第三方转发这个调用。这个原则的基本思想是强调类之间的松耦合；类之间的耦合越弱，越有利于复用，弱耦合类的修改不会影响相关类。在类结构设计上，每个类都应该尽量减少成员的访问权限。6.合成/聚合复用原则尽量使用合成/聚合，尽量不要使用类继承。聚合代表一种弱“拥有”关系，即A对象可以包含B对象，但B对象不属于A对象；组合是一种强“拥有”关系，体现了严格的部分与整体的关系，部分与整体具有相同的生命周期。首先使用对象的组合/聚合将帮助您保持每个类的封装并完成单个任务，这样类和类继承层次结构保持较小并且不太可能成长为难以管理的庞然大物。7.UML实例图'+'表示public，'-'表示private，'#'表示protected；组合是一种很强的“拥有”关系，体现了部分与整体的严格关系，部分与整体的生命周期相同；继承关系实现关系关联关系聚合关系综合关系依赖关系空心三角形+实现空心三角形+虚线实心箭头空心菱形+实线箭头实心菱形+实线箭头虚线箭头在UML类图中，常见的有如下几种关系：Generalization,Realization,Association,Aggregation,Composition,Dependency1.泛化【泛化关系】：是一种继承关系，表示一般和特殊的关系，规定了子类如何特化父类的所有特征和行为。例如：老虎是动物的一种，即既有老虎的特点，又有动物的共性。[ArrowPointing]:一条带三角箭头的实线，指向父类2.实现(Realization)[RealizationRelationship]:是一个类和一个接口的关系，表示该类是所有特性的实现和接口的行为。[ArrowPointing]:带三角箭头的虚线，箭头指向接口3。比如：师生关系，夫妻关系，可以是双向的，也可以是单向的。双向关联可以有两个箭头或没有箭头，单向关联可以有一个箭头。【代码体现】：成员变量【箭头及指向】：带普通箭头的实线，指向所有者。例如，汽车和轮胎是整体-部分的关系，没有汽车轮胎仍然可以存在。聚合关系是关联关系的一种，是一种强关联关系；association和aggregation在语法上无法区分，必须考察具体的逻辑关系。,【代码体现】：成员变量【箭头和方向】：空心菱形的实线，菱形指向整体。如果一个公司和一个部门是整体关系，那么就没有公司就没有部门。组合关系是一种关联关系，比聚合关系更强。它要求普通聚合关系中代表整体的对象负责代表部分的对象的生命周期。【代码体现】：成员变量【箭头和指向】：实心菱形的实线，菱形指向整体，所以尽量不要使用双向依赖。【代码表现】：局部变量、方法参数或调用静态方法弱序：泛化=实现>组合>聚合>关联>依赖
