面向对象的设计原则-类设计原则资料

1、面向对象的设计原则类设计原则在面向对象设计中，如何通过很小的设计改变就可以应对设计需求的变化，这是令设计者极为关注的问题。为此不少OO先驱提出了很多有关面向对象的设计原则用于指导OO的设计和开发。下面是几条与类设计相关的设计原则。1. 开闭原则（the Open Closed Principle OCP）一个模块在扩展性方面应该是开放的而在更改性方面应该是封闭的。因此在进行面向对象设计时要尽量考虑接口封装机制、抽象机制和多态技术。该原则同样适合于非面向对象设计的方法，是软件工程 设计方法的重要原则之一。我们以收音机的例子为例，讲述面向对象的开闭原则。我们收听节目时需要打开收音机电源，对准电台频

2、率和进行音量调节。但是对于不同的收音机，实现这三个步骤的细节往往有所不同。比如自动收缩电台的收音机和按钮式收缩在操作细节上并不相同。因此，我们不太可能针对每种不同类型的收音机通过一个收音机类来实现（通过重载）这些不同的操作方式。但是我们可以定义一个收音机接口，提供开机、关机、增加频率、降低频率、增加音量、降低音量六个抽象方法。不同的收音机继承并实现这六个抽象方法。这样新增收音机类型不会影响其它原有的收音机类型，收音机类型扩展极为方便。此外，已存在的收音机类型在修改其操作方法时也不会影响到其它类型的收音机。图1是一个应用OCP生成的收音机类图的例子：图12. 替换原则 (the Liskov S

3、ubstitution Principle LSP)子类应当可以替换父类并出现在父类能够出现的任何地方。这个原则是Liskov于1987年提出的设计原则。它同样可以从Bertrand Meyer 的DBC (Design by Contract) 的概念推出。我们以学生为例，夜校生为学生的子类，因此在任何学生可以出现的地方，夜校生均可出现。这个例子有些牵强，一个能够反映这个原则的例子时圆和椭圆，圆是椭圆的一个特殊子类。因此任何出现椭圆的地方，圆均可以出现。但反过来就可能行不通。Liskov的相关图示见图2：Page 1图2 Liskov 原则运用替换原则时，我们尽量把B设计为抽象类或者接口，让

4、C继承B（接口B）并实现操作A和操作B，运行时，C实例替换B，这样我们即可进行新类的扩展（继承类B或接口B），同时无须对A进行修改。3. 依赖原则 (the Dependency Inversion Principle DIP)在进行业务设计时，与特定业务有关的依赖关系应该尽量依赖接口和抽象类，而不是依赖于具体类。具体类只负责相关业务的实现，修改具体类不影响与特定业务有关的依赖关系。在结构化设计中，我们可以看到底层的模块是对高层抽象模块的实现（高层抽象模块通过调用底层模块），这说明，抽象的模块要依赖具体实现相关的模块，底层模块的具体实现发生变动时将会严重影响高层抽象的模块，显然这是结构化方法的

5、一个"硬伤"。面向对象方法的依赖关系刚好相反，具体实现类依赖于抽象类和接口（见图-3）。为此，我们在进行业务设计时，应尽量在接口或抽象类中定义业务方法的原型，并通过具体的实现类（子类）来实现该业务方法，业务方法内容的修改将不会影响到运行时业务方法的调用。图3依赖原则图示Page 24. 接口分离原则（the Interface Segregation Principle ISP）采用多个与特定客户类有关的接口比采用一个通用的涵盖多个业务方法的接口要好。ISP原则是另外一个支持诸如COM等组件化的使能技术。缺少ISP，组件、类的可用性和移植性将大打折扣。这个原则的本质相当简单

6、。如果你拥有一个针对多个客户的类，为每一个客户创建特定业务接口，然后使该客户类继承多个特定业务接口将比直接加载客户所需所有方法有效。图4展示了一个拥有多个客户的类。它通过一个巨大的接口来服务所有的客户。只要针对客户A的方法发生改变，客户B和客户C就会受到影响。因此可能需要进行重新编译和发布。这是一种不幸的做法。图4 带有集成接口的服务类我们再看图-5中所展示的技术。每个特定客户所需的方法被置于特定的接口中，这些接口被Service类所继承并实现。如果针对客户A的方法发生改变，客户B和客户C并不会受到任何影响，也不需要进行再次编译和重新发布。以上四个原则是面向对象中常常用到的原则。此外，除上述四

7、原则外，还有一些常用的经验诸如类结构层次以三到四层为宜、类的职责明确化（一个类对应一个具体职责）等可供我Page 3们在进行面向对象设计参考。但就上面的几个原则看来，我们看到这些类在几何分布上呈现树型拓扑的关系，这是一种良好、开放式的线性关系、具有较低的设计复杂度。一般说来，在软件设计中我们应当尽量避免出现带有闭包、循环的设计关系，它们反映的是较大的耦合度和设计复杂化。面向对象设计原则面向对象设计原则面向对象设计的基石是“开闭”原则。正在装载数据“开一闭”原则讲的是：一个软件实体应当对扩展开放，对修改关闭。这个规则说的是，在设计一个模块的时候，应当使这个模块可以在不被修改的前提下被扩展。从另外

8、一个角度讲，就是所谓的“对可变性封装原则”。“对可变性封装原则”意味着两点：1 .一种可变性不应当散落在代码的很多角落里，而应当被封装到一个对象里面。同一种可变性的不同表象意味着同一个继承等级结构中的具体子类。2.一种可变性不应当与另一种可变性混合在一起。即类图的继承结构一般不应超过两层。做到“开闭”原则不是一件容易的事，但是也有很多规律可循，这些规律同样也是设计原则，它们是实现开闭原则的工具。里氏代换原则里氏代换原则：如果对每一个类型为T1的对象o1,都有类型为T2的对象o2，使得以T1定义的所有程序P在所有对象o1都换成o2时，程序P的行为没有变化，那么类型T2是T1的子类型。即如果一个软

9、件实体使用的是基类的话那么也一定适用于子类。但反过来的代换不成立。如果有两个具体类A和B之间的关系违反了里氏代换原则，可以在以下两种重构方案中选择一种：1 .创建一个新的抽象类C,作为两个具体类的超类，将A和B共同的行为移动到C中，从而解决A和B行为不完全一致的问题。2 .从B到A的继承关系改写为委派关系。依赖倒转原则依赖倒转原则讲的是：要依赖于抽象，不要依赖于具体。即针对接口编程，不要针对实现编程。针对接口编程的意思是，应当使用接口和抽象类进行变量的类型声明、参量的类型声明，方法的返还类型声明，以及数据类型的转换等。不要针对实现编程的意思就是说，不应当使用具体类进行变量的类型声明、参量的类型

10、声明，方法的返还类型声明，以及数据类型的转换等。依赖倒转原则虽然强大，但却不易实现，因为依赖倒转的缘故，对象的创建很可能要使Page 4用对象工厂，以避免对具体类的直接引用，此原则的使用还会导致大量的类。维护这样的系统需要较好的面向对象的设计知识。此外，依赖倒转原则假定所有的具体类都是变化的，这也不总是正确的。有一些具体类可能是相当稳定、不会发生变化的，消费这个具体类实例的客户端完全可以依赖于这个具体类。接口隔离原则接口隔离原则讲的是：使用多个专门的接口比使用单一的接口要好。从客户的角度来说：一个类对另外一个类的依赖性应当是建立在最小的接口上的。如果客户端只需要某一些方法的话，那么就应当向客户

11、端提供这些需要的方法，而不要提供不需要的方法。提供接口意味着向客户端作出承诺，过多的承诺会给系统的维护造成不必要的负担。合成、聚合复用原则合成、聚合复用原则就是在一个新的对象里面使用一些已有的对象，使之成为新对象的一部份，新的对象通过向这些对象的委派达到复用已有功能的目的。这个原则有一个简短的描述：要尽量使用合成、聚合，尽量不要使用继承。合成、聚合有如下好处：新对象存取成分对象的唯一方法是通过成分对象的接口。这种复用是黑箱复用，因为成分对象的内部细节是新对象所看不到的。这种复用可以在运行时间内动态进行，新对象可以动态的引用与成分对象类型相同的对象。 合成、聚合可以应用到任何环境中去，而继承只能

12、应用到一些有限环境中去。导致错误的使用合成、聚合与继承的一个常见原因是错误的把“Has-a”关系当作“Is-a”关系。如果两个类是“Has-a”关系那么应使用合成、聚合，如果是“Is-a”关系那么可使用继承。迪米特法则迪米特法则说的是一个对象应该对其它对象有尽可能少的了解。即只与你直接的朋友通信，不要跟陌生人说话。如果需要和陌生人通话，而你的朋友与陌生人是朋友，那么可以将你对陌生人的调用由你的朋友转发，使得某人只知道朋友，不知道陌生人。换言之，某人会认为他所调用的是朋友的方法。以下条件称为朋友的条件：当前对象本身。以参量的形式传入到当前对象方法中的对象。当前对象的实例变量直接引用的对象。当前对

13、象的实例变量如果是一个聚集，那么聚集中的元素也都是朋友。当前对象所创建的对象。任何一个对象，如果满足上面的条件之一，就是当前对象的朋友，否则就是陌生人。迪米特法则的主要用意是控制信息的过载，在将其运用到系统设计中应注意以下几点： 在类的划分上，应当创建有弱耦合的类。类之间的耦合越弱，就越有利于复用。在类的结构设计上，每一个类都应当尽量降低成员的访问权限。一个类不应当public自己的属性，而应当提供取值和赋值的方法让外界间接访问自己的属性。Page 5在类的设计上，只要有可能，一个类应当设计成不变类。在对其它对象的引用上，一个类对其它对象的引用应该降到最低。一个良好的面向对象设计需要遵循一些基

14、本原则，如单一职责原则（SRP）、开放-封闭原则（OCP）、Liskov替换原则（LSP）、依赖倒置原则（DIP）、接口分离原则（ISP）等。1、 单一职责原则（SRP）描述：就一个类而言，应该仅有一个引起它变化的原因。应用：在构造对象时，将对象的不同职责分离至两个或多个类中，确保引起该类变化的原因只有一个。带来的好处：提高内聚、降低耦合。个人观点：该原则可以有效降低耦合，减少对不必要资源的引用。但后果是造成源文件增多，给管理带来不便，所以在实际应用中，可以对经常使用或经常需要改动的模块应用该原则。2、 开放-封闭原则（OCP）描述："对于扩展是开放的"（Open for

15、extension）。这意味着模块的行为是可以扩展的。当应用的需求改变时，可以对模块进行扩展，使其具有满足改变的新行为。也就是说，我们可以改变模块的功能。"对于更改是封闭的"（Close for modification）。对模块行为进行扩展时，不必改动模块的源代码或者二进制代码。应用：高级语言中的接口与虚拟类。带来的好处：提高灵活性、可重用性、可维护性。个人观点：OCP的关键是抽象，抽象的目的是创建一个固定却能够描述一组任意个可能行为的基类。而这一组可能的行为则表现为派生类。对于基类的更改是封闭的，所以它里边的方法一旦确定就不能更改（对接口里的方法进行更改将带来灾难性的后

16、果）。模块通过抽象基类进行引用，对派生类的扩展并不影响整个模块，所以它是开放的。遵循OCP的代价也是昂贵的，创建正确的抽象是要花费开发时间和精力的，同时抽象也增加了软件设计的复杂性。因此有效的预知变化是OCP设计的要点，这需要我们进行适当的调查，提出正确的问题，并利用我们的经验和一般常识来做出判断。正确的做法是，只对程序中频繁变化的部分做出抽象，拒绝不成熟的抽象和抽象本身一样重要。3、 Liskov替换原则（LSP）描述：若对每个类型S的对象O1，都存在一个类型T的对象O2，使得在所有针对T编写的程序P中，用O1替换O2后，程序P行为功能不变，则S是T的子类型。应用：在实现继承时，子类型（su

17、btype）必须能替换掉它们的基类型（base type）。如果一个软件实体使用的是基类的话那么也一定适用于子类。但反过来的代换不成立。个人观点： LSP是使OCP成为可能的主要原则之一，对LSP的违反将导致对OCP的违反，同时二者是OOD中抽象和多态的理论基础，在OOPL中表现为继承。在高级语言（JAVA、C#）中，只要我们严格按照接口和虚拟类的语法规范来做就能很好遵循此原则，另外我们还应该避免一些更微妙的违规情况。举个例子，正方形和矩形，矩形可以做为正方形的基类，因为正方形也是一种矩形，但对于正方形来说，setWidth()和setHeight()是冗余的，且容易引起错误，这样的设计就违反

18、了LSP原则。如果有两个具体类A和B之间的关系违反了LSP，Page 6可以在以下两种重构方案中选择一种：1 .创建一个新的抽象类C,作为两个具体类的超类，将A和B共同的行为移动到C中，从而解决A和B行为不完全一致的问题。 2 .从B到A的继承关系改写为委派关系。4、 依赖倒置原则（DIP）描述：A .高层模块不应该依赖于低层模块。二者都应该依赖于抽象。B .抽象不应该依赖于细节。细节应该依赖于抽象。应用：要依赖抽象，不要依赖于具体。即针对接口编程，不要针对实现编程。针对接口编程的意思是，应当使用接口和抽象类进行变量的类型声明、参量的类型声明，方法的返还类型声明，以及数据类型的转换等。不要针对

19、实现编程的意思就是说，不应当使用具体类进行变量的类型声明、参量的类型声明，方法的返还类型声明，以及数据类型的转换等。结论：DIP虽然强大，但却不易实现，因为依赖倒转的缘故，对象的创建很可能要使用对象工厂，以避免对具体类的直接引用，此原则的使用将导致大量的类文件。给维护带来不必要的麻烦。所以，正确的做法是只对程序中频繁变化的部分进行依赖倒置。5、 接口隔离原则（ISP）描述：不要强迫客户依赖于它们不用的方法。应用：一个类对另外一个类的依赖性应当是建立在最小的接口上的。如果客户端只需要某一些方法的话，那么就应当向客户端提供这些需要的方法，而不要提供不需要的方法。提供接口意味着向客户端作出承诺，过多

20、的承诺会给系统的维护造成不必要的负担。结论：使用多个专门的接口比使用单一的接口要好。遵循以上原则，可以使我们的软件更具灵活性，强壮性。但灵活是需要付出代价的，由多态带来的性能损失就是最明显的一个问题。所以我们需要权衡，需要做出选择，在灵活与性能之间做出选择。追本溯源，促使我们使用这些原则的原因是为了满足需求的变更，于是需求分析就显得格外重要。然而不管怎么充分的需求分析都可能遭遇需求变更，于是预测变化就成了一个让人头痛的事。还是让我们来看看敏捷设计（XP）是怎么解决这些问题的："敏捷开发人员不会对一个庞大的预先设计应用那些原则和模式，相反，这些原则和模式被应用在一次次的迭代中，力图使代

21、码以及代码所表达的设计保持干净。"也就是说敏捷设计通过快速的迭代来刺激变化，让这些变化及早暴露，再根据变化进行相应改动。很明显这要比一次性完整设计轻松容易的多。最后引用透明在书评中的一句话来结束这篇blog。"软件开发的全部艺术就是权衡：在简单与复杂之间权衡，在一种方案与另一种方案之间权衡。如果把每个问题、每个权衡的利弊都考虑得清清楚楚，恐怕开发一个应用程序的成本会高得惊人。所以，很多时候我们更依赖自己的审美眼光，用平静的心去设计一个赏心悦目的系统。"Page 761条Java面向对象设计的经验原则(1)所有数据都应该隐藏在所在的类的内部。(2)类的使用者必须依赖

22、类的共有接口，但类不能依赖它的使用者。(3)尽量减少类的协议中的消息。(4)实现所有类都理解的最基本公有接口例如，拷贝操作(深拷贝和浅拷贝)、相等性判断、正确输出内容、从ASCII描述解析等等.(5)不要把实现细节(例如放置共用代码的私有函数)放到类的公有接口中。如果类的两个方法有一段公共代码，那么就可以创建一个防止这些公共代码的私有函数。(6)不要以用户无法使用或不感兴趣的东西扰乱类的公有接口。(7)类之间应该零耦合，或者只有导出耦合关系。也即，一个类要么同另一个类毫无关系，要么只使用另一个类的公有接口中的操作。(8)类应该只表示一个关键抽象。包中的所有类对于同一类性质的变化应该是共同封闭的

23、。一个变化若对一个包影响，则将对包中的所有类产生影响，而对其他的包不造成任何影响.(9)把相关的数据和行为集中放置。设计者应当留意那些通过get之类操作从别的对象中获取数据的对象。这种类型的行为暗示着这条经验原则被违反了。(10)把不相关的信息放在另一个类中(也即：互不沟通的行为)。朝着稳定的方向进行依赖。(11)确保你为之建模的抽象概念是类，而不只是对象扮演的角色。类应当统一地共享工作。(13)在你的系统中不要创建全能类/对象。对名字包含Driver、Manager、System、Susystem的类要特别多加小心。规划一个接口而不是实现一个接口。(14)对公共接口中定义了大量访问方法的类多

24、加小心。大量访问方法意味着相关数据和行为没有集中存放。(15)对包含太多互不沟通的行为的类多加小心。这个问题的另一表现是在你的应用程序中的类的公有接口中创建了很多的get和set函数。Page 8(16)在由同用户界面交互的Java面向对象模型构成的应用程序中，模型不应该依赖于界面，界面则应当依赖于模型。(17)尽可能地按照现实世界建模(我们常常为了遵守系统功能分布原则、避免全能类原则以及集中放置相关数据和行为的原则而违背这条原则).(18)从你的设计中去除不需要的类。一般来说，我们会把这个类降级成一个属性。(19)去除系统外的类。系统外的类的特点是，抽象地看它们只往系统领域发送消息但并不接受

25、系统领域内其他类发出的消息。(20)不要把操作变成类。质疑任何名字是动词或者派生自动词的类，特别是只有一个有意义行为的类。考虑一下那个有意义的行为是否应当迁移到已经存在或者尚未发现的某个类中。(21)我们在创建应用程序的分析模型时常常引入代理类。在设计阶段，我们常会发现很多代理没有用的，应当去除。(22)尽量减少类的协作者的数量。一个类用到的其他类的数目应当尽量少。(23)尽量减少类和协作者之间传递的消息的数量。(24)尽量减少类和协作者之间的协作量，也即：减少类和协作者之间传递的不同消息的数量。(25)尽量减少类的扇出，也即：减少类定义的消息数和发送的消息数的乘积。(26)如果类包含另一个类

26、的对象，那么包含类应当给被包含的对象发送消息。也即：包含关系总是意味着使用关系。(27)类中定义的大多数方法都应当在大多数时间里使用大多数数据成员。(28)类包含的对象数目不应当超过开发者短期记忆的容量。这个数目常常是6.当类包含多于6个数据成员时，可以把逻辑相关的数据成员划分为一组，然后用一个新的包含类去包含这一组成员。(29)让系统功能在窄而深的继承体系中垂直分布。(30)在实现语义约束时，最好根据类定义来实现。这常常会导致类泛滥成灾，在这种情况下，约束应当在类的行为中实现，通常是在构造函数中实现，但不是必须如此。Page 9(31)在类的构造函数中实现语义约束时，把约束测试放在构造函数领

27、域所允许的尽量深的包含层次中。(32)Java面向对象中，约束所依赖的语义信息如果经常改变，那么最好放在一个集中式的第3方对象中。(33)约束所依赖的语义信息如果很少改变，那么最好分布在约束所涉及的各个类中。(34)类必须知道它包含什么，但是不能知道谁包含它。(35)共享字面范围(也就是被同一个类所包含)的对象相互之间不应当有使用关系。(36)继承只应被用来为特化层次结构建模。(37)派生类必须知道基类，基类不应该知道关于它们的派生类的任何信息。(38)基类中的所有数据都应当是私有的，不要使用保护数据。类的设计者永远都不应该把类的使用者不需要的东西放在公有接口中。(39)在理论上，继承层次体系

28、应当深一点，越深越好。(40)在实践中，继承层次体系的深度不应当超出一个普通人的短期记忆能力。一个广为接受的深度值是6.(41)所有的抽象类都应当是基类。(42)所有的基类都应当是抽象类。(43)把数据、行为和/或接口的共性尽可能地放到继承层次体系的高端。(44)如果两个或更多个类共享公共数据(但没有公共行为)，那么应当把公共数据放在一个类中，每个共享这个数据的类都包含这个类。(45)如果两个或更多个类有共同的数据和行为(就是方法)，那么这些类的每一个都应当从一个表示了这些数据和方法的公共基类继承。(46)如果两个或更多个类共享公共接口(指的是消息，而不是方法)，那么只有他们需要被多态地使用时

29、，他们才应当从一个公共基类继承。(47)对对象类型的显示的分情况分析一般是错误的。在大多数这样的情况下，设计者应当使用多态。(48)对属性值的显示的分情况分析常常是错误的。类应当解耦合成一个继承层次结构，每个属性值都被变换成一个派生类。Page 10(49)不要通过继承关系来为类的动态语义建模。试图用静态语义关系来为动态语义建模会导致在运行时切换类型。(50)不要把类的对象变成派生类。对任何只有一个实例的派生类都要多加小心。(51)如果你觉得需要在运行时刻创建新的类，那么退后一步以认清你要创建的是对象。现在，把这些对象概括成一个类。(52)在派生类中用空方法(也就是什么也不做的方法)来覆写基类

30、中的方法应当是非法的。(53)不要把可选包含同对继承的需要相混淆。把可选包含建模成继承会带来泛滥成灾的类。(54)在创建继承层次时，试着创建可复用的框架，而不是可复用的组件。(55)如果你在设计中使用了多重继承，先假设你犯了错误。如果没犯错误，你需要设法证明。(56)只要在Java面向对象设计中用到了继承，问自己两个问题：(1)派生类是否是它继承的那个东西的一个特殊类型？(2)基类是不是派生类的一部分？(57)如果你在一个面向对象设计中发现了多重继承关系，确保没有哪个基类实际上是另一个基类的派生类。(58)在面向对象设计中如果你需要在包含关系和关联关系间作出选择，请选择包含关系。(59)不要把

31、全局数据或全局函数用于类的对象的薄记工作。应当使用类变量或类方法。(60)Java面向对象设计者不应当让物理设计准则来破坏他们的逻辑设计。但是，在对逻辑设计作出决策的过程中我们经常用到物理设计准则。(61)不要绕开公共接口去修改对象的状态。面向对象分析 面向对象分析（Object-Oriented Analysis，OOA，面向对象分析方法），是在一个系统的开发过程中进行了系统业务调查以后，按照面向对象的思想来分析问题。OOA与结构化分析有较大的区别。OOA所强调的是在系统调查资料的基础上，针对OO方法所需要的素材进行的归类分析和整理，而不是对管理业务现状和方法的分析。OOA（面向对象的分析）

32、模型由5个层次（主题层、对象类层、结构层、属性层和服务层）和5个活动（标识对象类、标识结构、定义主题、定义属性和定义服务）组成。在这种方法中定义了两种对象类之间的结构，一种称为分类结构，一种称为组装结构。分类结构就是所谓的一般与特殊的关系。组装结构则反映了对象之间的整体与部分的关系。Page 11OOA在定义属性的同时，要识别实例连接。实例连接是一个实例与另一个实例的映射关系。OOA在定义服务的同时要识别连接。当一个对象需要向另一对象发送消息时，它们之间就存在消息连接。OOA 中的5个层次和5个活动继续贯穿在（画向对象的设计）过程中。OOD模型由4个部分组成。它们分别是设计问题域部分、设计人机

33、交互部分、设计任务管理部分设计数据管理部分。一、OOA的主要原则。（1）抽象：从许多事物中舍弃个别的、非本质的特征，抽取共同的、本质性的特征，就叫作抽象。抽象是形成概念的必须手段。抽象原则有两方面的意义：第一，尽管问题域中的事物是很复杂的，但是分析员并不需要了解和描述它们的一切，只需要分析研究其中与系统目标有关的事物及其本质性特征。第二，通过舍弃个体事物在细节上的差异，抽取其共同特征而得到一批事物的抽象概念。抽象是中使用最为广泛的原则。抽象原则包括过程抽象和数据抽象两个方面。过程抽象是指，任何一个完成确定功能的操作序列，其使用者都可以把它看作一个单一的实体，尽管实际上它可能是由一系列更低级的操

34、作完成的。 数据抽象是根据施加于数据之上的操作来定义数据，并限定数据的值只能由这些操作来修改和观察。数据抽象是OOA的核心原则。它强调把数据（属性）和操作（服务）结合为一个不可分的系统单位（即对象），对象的外部只需要知道它做什么，而不必知道它如何做。（2）封装就是把对象的属性和服务结合为一个不可分的系统单位，并尽可能隐蔽对象的内部细节。（3）继承：特殊类的对象拥有的其一般类的全部属性与服务，称作特殊类对一般类的继承。在OOA中运用继承原则，就是在每个由一般类和特殊类形成的一般特殊结构中，把一般类的对象实例和所有特殊类的对象实例都共同具有的属性和服Page 12务，一次性地在一般类中进行显式的定义。在特殊类中不再重复地定义一般类中已定义的东西，但是在语义上，特殊类却自动地、隐含地拥有它的一般类（以及所有更上层的一般类）中定义的全部属性和服务。继承原则的好处是：使系统模型比较简练也比较清晰。（4）分类：就是把具有相同属性和服务的对象划分为一类，用类作为这些对象的抽象描述。分类原则实际上是抽象原则