RSS订阅
生活小妙招
当前位置：称心常识网 > 百科 > 正文

面向对象设计原则（面向对象设计原则详解）

  • 半米阳光 发布于 2019-12-08 00:56
  • 分类：百科
  • 阅读(5)

面向对象设计原则

61条Java面向对象设计的经验原则 是什么？

  • 完整问题：61条Java面向对象设计的经验原则 是什么？
  • 好评回答：1）所有数据都应该隐藏在所在的类的内部。（2）类的使用者必须依赖类的共有接口，但类不能依赖它的使用者。（3）尽量减少类的协议中的消息。（4）实现所有类都理解的最基本公有接口[例如，拷贝操作（深拷贝和浅拷贝）、相等性判断、正确输出内容、从ASCII描述解析等等]。（5）不要把实现细节（例如放置共用代码的私有函数）放到类的公有接口中。如果类的两个方法有一段公共代码，那么就可以创建一个防止这些公共代码的私有函数。（6）不要以用户无法使用或不感兴趣的东西扰乱类的公有接口。（7）类之间应该零耦合，或者只有导出耦合关系。也即，一个类要么同另一个类毫无关系，要么只使用另一个类的公有接口中的操作。（8）类应该只表示一个关键抽象。包中的所有类对于同一类性质的变化应该是共同封闭的。一个变化若对一个包影响，则将对包中的所有类产生影响，而对其他的包不造成任何影响 。（9）把相关的数据和行为集中放置。设计者应当留意那些通过get之类操作从别的对象中获取数据的对象。这种类型的行为暗示着这条经验原则被违反了。（10）把不相关的信息放在另一个类中（也即：互不沟通的行为）。朝着稳定的方向进行依赖。（11）确保你为之建模的抽象概念是类，而不只是对象扮演的角色。类应当统一地共享工作。（13）在你的系统中不要创建全能类/对象。对名字包含Driver、Manager、System、Susystem的类要特别多加小心。规划一个接口而不是实现一个接口。（14）对公共接口中定义了大量访问方法的类多加小心。大量访问方法意味着相关数据和行为没有集中存放。（15）对包含太多互不沟通的行为的类多加小心。这个问题的另一表现是在你的应用程序中的类的公有接口中创建了很多的get和set函数。（16）在由同用户界面交互的Java面向对象模型构成的应用程序中，模型不应该依赖于界面，界面则应当依赖于模型。（17）尽可能地按照现实世界建模（我们常常为了遵守系统功能分布原则、避免全能类原则以及集中放置相关数据和行为的原则而违背这条原则） 。（18）从你的设计中去除不需要的类。一般来说，我们会把这个类降级成一个属性。（19）去除系统外的类。系统外的类的特点是，抽象地看它们只往系统领域发送消息但并不接受系统领域内其他类发出的消息。（20）不要把操作变成类。质疑任何名字是动词或者派生自动词的类，特别是只有一个有意义行为的类。考虑一下那个有意义的行为是否应当迁移到已经存在或者尚未发现的某个类中。（21）我们在创建应用程序的分析模型时常常引入代理类。在设计阶段，我们常会发现很多代理没有用的，应当去除。（22）尽量减少类的协作者的数量。一个类用到的其他类的数目应当尽量少。（23）尽量减少类和协作者之间传递的消息的数量。（24）尽量减少类和协作者之间的协作量，也即：减少类和协作者之间传递的不同消息的数量。（25）尽量减少类的扇出，也即：减少类定义的消息数和发送的消息数的乘积。（26）如果类包含另一个类的对象，那么包含类应当给被包含的对象发送消息。也即：包含关系总是意味着使用关系。（27）类中定义的大多数方法都应当在大多数时间里使用大多数数据成员。（28）类包含的对象数目不应当超过开发者短期记忆的容量。这个数目常常是6。当类包含多于6个数据成员时，可以把逻辑相关的数据成员划分为一组，然后用一个新的包含类去包含这一组成员。（29）让系统功能在窄而深的继承体系中垂直分布。（30）在实现语义约束时，最好根据类定义来实现。这常常会导致类泛滥成灾，在这种情况下，约束应当在类的行为中实现，通常是在构造函数中实现，但不是必须如此。（31）在类的构造函数中实现语义约束时，把约束测试放在构造函数领域所允许的尽量深的包含层次中。（32）Java面向对象中，约束所依赖的语义信息如果经常改变，那么最好放在一个集中式的第3方对象中。（33）约束所依赖的语义信息如果很少改变，那么最好分布在约束所涉及的各个类中。（34）类必须知道它包含什么，但是不能知道谁包含它。（35）共享字面范围（也就是被同一个类所包含）的对象相互之间不应当有使用关系。（36）继承只应被用来为特化层次结构建模。（37）派生类必须知道基类，基类不应该知道关于它们的派生类的任何信息。（38）基类中的所有数据都应当是私有的，不要使用保护数据。类的设计者永远都不应该把类的使用者不需要的东西放在公有接口中。（39）在理论上，继承层次体系应当深一点，越深越好。（40）在实践中，继承层次体系的深度不应当超出一个普通人的短期记忆能力。一个广为接受的深度值是6。（41）所有的抽象类都应当是基类。（42）所有的基类都应当是抽象类。（43）把数据、行为和/或接口的共性尽可能地放到继承层次体系的高端。（44）如果两个或更多个类共享公共数据（但没有公共行为），那么应当把公共数据放在一个类中，每个共享这个数据的类都包含这个类。（45）如果两个或更多个类有共同的数据和行为（就是方法），那么这些类的每一个都应当从一个表示了这些数据和方法的公共基类继承。（46）如果两个或更多个类共享公共接口（指的是消息，而不是方法），那么只有他们需要被多态地使用时，他们才应当从一个公共基类继承。（47）对对象类型的显示的分情况分析一般是错误的。在大多数这样的情况下，设计者应当使用多态。（48）对属性值的显示的分情况分析常常是错误的。类应当解耦合成一个继承层次结构，每个属性值都被变换成一个派生类。（49）不要通过继承关系来为类的动态语义建模。试图用静态语义关系来为动态语义建模会导致在运行时切换类型。（50）不要把类的对象变成派生类。对任何只有一个实例的派生类都要多加小心。（51）如果你觉得需要在运行时刻创建新的类，那么退后一步以认清你要创建的是对象。现在，把这些对象概括成一个类。（52）在派生类中用空方法（也就是什么也不做的方法）来覆写基类中的方法应当是非法的。（53）不要把可选包含同对继承的需要相混淆。把可选包含建模成继承会带来泛滥成灾的类。（54）在创建继承层次时，试着创建可复用的框架，而不是可复用的组件。（55）如果你在设计中使用了多重继承，先假设你犯了错误。如果没犯错误，你需要设法证明。（56）只要在Java面向对象设计中用到了继承，问自己两个问题：（1）派生类是否是它继承的那个东西的一个特殊类型？（2）基类是不是派生类的一部分？（57）如果你在一个面向对象设计中发现了多重继承关系，确保没有哪个基类实际上是另一个基类的派生类。（58）在面向对象设计中如果你需要在包含关系和关联关系间作出选择，请选择包含关系。（59）不要把全局数据或全局函数用于类的对象的薄记工作。应当使用类变量或类方法。（60）Java面向对象设计者不应当让物理设计准则来破坏他们的逻辑设计。但是，在对逻辑设计作出决策的过程中我们经常用到物理设计准则。（61）不要绕开公共接口去修改对象的状态。

    • 61条Java面向对象设计的经验原则 是什么？

  • 完整问题：61条Java面向对象设计的经验原则 是什么？
  • 好评回答：1）所有数据都应该隐藏在所在的类的内部。（2）类的使用者必须依赖类的共有接口，但类不能依赖它的使用者。（3）尽量减少类的协议中的消息。（4）实现所有类都理解的最基本公有接口[例如，拷贝操作（深拷贝和浅拷贝）、相等性判断、正确输出内容、从ASCII描述解析等等]。（5）不要把实现细节（例如放置共用代码的私有函数）放到类的公有接口中。如果类的两个方法有一段公共代码，那么就可以创建一个防止这些公共代码的私有函数。（6）不要以用户无法使用或不感兴趣的东西扰乱类的公有接口。（7）类之间应该零耦合，或者只有导出耦合关系。也即，一个类要么同另一个类毫无关系，要么只使用另一个类的公有接口中的操作。（8）类应该只表示一个关键抽象。包中的所有类对于同一类性质的变化应该是共同封闭的。一个变化若对一个包影响，则将对包中的所有类产生影响，而对其他的包不造成任何影响 。（9）把相关的数据和行为集中放置。设计者应当留意那些通过get之类操作从别的对象中获取数据的对象。这种类型的行为暗示着这条经验原则被违反了。（10）把不相关的信息放在另一个类中（也即：互不沟通的行为）。朝着稳定的方向进行依赖。（11）确保你为之建模的抽象概念是类，而不只是对象扮演的角色。类应当统一地共享工作。（13）在你的系统中不要创建全能类/对象。对名字包含Driver、Manager、System、Susystem的类要特别多加小心。规划一个接口而不是实现一个接口。（14）对公共接口中定义了大量访问方法的类多加小心。大量访问方法意味着相关数据和行为没有集中存放。（15）对包含太多互不沟通的行为的类多加小心。这个问题的另一表现是在你的应用程序中的类的公有接口中创建了很多的get和set函数。（16）在由同用户界面交互的Java面向对象模型构成的应用程序中，模型不应该依赖于界面，界面则应当依赖于模型。（17）尽可能地按照现实世界建模（我们常常为了遵守系统功能分布原则、避免全能类原则以及集中放置相关数据和行为的原则而违背这条原则） 。（18）从你的设计中去除不需要的类。一般来说，我们会把这个类降级成一个属性。（19）去除系统外的类。系统外的类的特点是，抽象地看它们只往系统领域发送消息但并不接受系统领域内其他类发出的消息。（20）不要把操作变成类。质疑任何名字是动词或者派生自动词的类，特别是只有一个有意义行为的类。考虑一下那个有意义的行为是否应当迁移到已经存在或者尚未发现的某个类中。（21）我们在创建应用程序的分析模型时常常引入代理类。在设计阶段，我们常会发现很多代理没有用的，应当去除。（22）尽量减少类的协作者的数量。一个类用到的其他类的数目应当尽量少。（23）尽量减少类和协作者之间传递的消息的数量。（24）尽量减少类和协作者之间的协作量，也即：减少类和协作者之间传递的不同消息的数量。（25）尽量减少类的扇出，也即：减少类定义的消息数和发送的消息数的乘积。（26）如果类包含另一个类的对象，那么包含类应当给被包含的对象发送消息。也即：包含关系总是意味着使用关系。（27）类中定义的大多数方法都应当在大多数时间里使用大多数数据成员。（28）类包含的对象数目不应当超过开发者短期记忆的容量。这个数目常常是6。当类包含多于6个数据成员时，可以把逻辑相关的数据成员划分为一组，然后用一个新的包含类去包含这一组成员。（29）让系统功能在窄而深的继承体系中垂直分布。（30）在实现语义约束时，最好根据类定义来实现。这常常会导致类泛滥成灾，在这种情况下，约束应当在类的行为中实现，通常是在构造函数中实现，但不是必须如此。（31）在类的构造函数中实现语义约束时，把约束测试放在构造函数领域所允许的尽量深的包含层次中。（32）Java面向对象中，约束所依赖的语义信息如果经常改变，那么最好放在一个集中式的第3方对象中。（33）约束所依赖的语义信息如果很少改变，那么最好分布在约束所涉及的各个类中。（34）类必须知道它包含什么，但是不能知道谁包含它。（35）共享字面范围（也就是被同一个类所包含）的对象相互之间不应当有使用关系。（36）继承只应被用来为特化层次结构建模。（37）派生类必须知道基类，基类不应该知道关于它们的派生类的任何信息。（38）基类中的所有数据都应当是私有的，不要使用保护数据。类的设计者永远都不应该把类的使用者不需要的东西放在公有接口中。（39）在理论上，继承层次体系应当深一点，越深越好。（40）在实践中，继承层次体系的深度不应当超出一个普通人的短期记忆能力。一个广为接受的深度值是6。（41）所有的抽象类都应当是基类。（42）所有的基类都应当是抽象类。（43）把数据、行为和/或接口的共性尽可能地放到继承层次体系的高端。（44）如果两个或更多个类共享公共数据（但没有公共行为），那么应当把公共数据放在一个类中，每个共享这个数据的类都包含这个类。（45）如果两个或更多个类有共同的数据和行为（就是方法），那么这些类的每一个都应当从一个表示了这些数据和方法的公共基类继承。（46）如果两个或更多个类共享公共接口（指的是消息，而不是方法），那么只有他们需要被多态地使用时，他们才应当从一个公共基类继承。（47）对对象类型的显示的分情况分析一般是错误的。在大多数这样的情况下，设计者应当使用多态。（48）对属性值的显示的分情况分析常常是错误的。类应当解耦合成一个继承层次结构，每个属性值都被变换成一个派生类。（49）不要通过继承关系来为类的动态语义建模。试图用静态语义关系来为动态语义建模会导致在运行时切换类型。（50）不要把类的对象变成派生类。对任何只有一个实例的派生类都要多加小心。（51）如果你觉得需要在运行时刻创建新的类，那么退后一步以认清你要创建的是对象。现在，把这些对象概括成一个类。（52）在派生类中用空方法（也就是什么也不做的方法）来覆写基类中的方法应当是非法的。（53）不要把可选包含同对继承的需要相混淆。把可选包含建模成继承会带来泛滥成灾的类。（54）在创建继承层次时，试着创建可复用的框架，而不是可复用的组件。（55）如果你在设计中使用了多重继承，先假设你犯了错误。如果没犯错误，你需要设法证明。（56）只要在Java面向对象设计中用到了继承，问自己两个问题：（1）派生类是否是它继承的那个东西的一个特殊类型？（2）基类是不是派生类的一部分？（57）如果你在一个面向对象设计中发现了多重继承关系，确保没有哪个基类实际上是另一个基类的派生类。（58）在面向对象设计中如果你需要在包含关系和关联关系间作出选择，请选择包含关系。（59）不要把全局数据或全局函数用于类的对象的薄记工作。应当使用类变量或类方法。（60）Java面向对象设计者不应当让物理设计准则来破坏他们的逻辑设计。但是，在对逻辑设计作出决策的过程中我们经常用到物理设计准则。（61）不要绕开公共接口去修改对象的状态。

    • 面向对象设计的设计结果应该是怎样的？

  • 完整问题：面向对象设计的设计结果应该是怎样的？
  • 好评回答：（二）面向对象设计的启发规则1.设计结果应该清晰易懂使设计结果清晰、易懂、易读是提高软件可维护性和可重用性的重要措施 以上是对这个问题的回答，希望对您有帮助。

    • 面向对象的核心原则是什么

  • 完整问题：
  • 好评回答：61条面向对象设计的经验原则摘抄自《OOD 启思录》–Arthur J。Riel 著 鲍志云 译 “你不必严格遵守这类原则，违背它们也不会被处以宗教刑罚。但你应当把这类原则看成警铃，若违背了其中的一条，那么警铃就会响起。” “你不必严格遵守这类原则，违背它们也不会被处以宗教刑罚。但你应当把这类原则看成警铃，若违背了其中的一条，那么警铃就会响起。” ———-Arthur J。Riel (1)全部数据都应当隐藏在所在的类的内部。p13 (2)类的用者必须依赖类的共有接口，但类不能依赖它的用者。p15 (3)尽量减少类的协议中的消息。p16 (4)实现全部类都理解的最基本公有接口[例如，拷贝操作(深拷贝和浅拷贝)、相等性判别、正确输出内容、从ASCII描述解析等等]。 p16 (5)别把实现细节(例如放置共用代码的私有函数)放到类的公有接口中。p17 假如类的2个方法有一段公共代码，那么就可以创建1个防止这类公共代码的私有函数。 (6)别以用户没方法用或不感兴趣的东东扰乱类的公有接口。p17 (7)类之间应当零耦合，或仅有导出耦合关系。也即，1个类要么同另1个类毫无关系，要么只用另1个类的公有接口中的操作。 p18 (8)类应当只表示1个关键抽象。p19 包中的全部类对于同一类性质的变化应当是共同封闭的。1个变化若对1个包影响，则将对包中的全部类产生影响，而对其他的包不造成任何影响 。 (9)把相关的数据和行为集中放置。p19 设计者应当留意那些通过get之类操作从别的对象中获取数据的对象。这种类型的行为暗示着这条经验原则被违反了。 (10)把不相关的信息放在另1个类中(也即：互不沟通的行为)。p19 朝着稳定的方向进行依赖。 (11)确保你为之建模的抽象概念是类，而不只是对象扮演的角色。p23 (12)在水平方向上尽可能统一地分布系统（System）功能，也即：按照设计，顶层类应当统一地共享工作。p30 (13)在你的系统（System）中别创建全能类/对象。对名字包含Driver、Manager、System、Susystem的类要特别多加小心。p30 规划1个接口而不是实现1个接口。 (14)对公共接口中定义了大量访问方法的类多加小心。大量访问方法意味着相关数据和行为木有集中存放。p30 (15)对包含太多互不沟通的行为的类多加小心。p31 这个问题的另一表现是在你的应用程序中的类的公有接口中创建了特别多的get和set函数。 (16)在由同用户界面交互的面向对象模型构成的应用程序中，模型不应当依赖于界面，界面则应当依赖于模型。p33 (17)尽可能地按照现实世界建模(我们常常为了遵守系统（System）功能分布原则、避免全能类原则以及集中放置相关数据和行为的原则而违背这条原则) 。p36 (18)从你的设计中去除不要的类。p38 一般来说，我们会把这个类降级成1个属性。 (19)去除系统（System）外的类。p39 系统（System）外的类的特点是，抽象地看它们只往系统（System）领域发送消息但并不接受系统（System）领域内其他类发出的消息。 (20)别把操作变成类。质疑任何名字是动词或派生自动词的类，特别是仅有1个有意义行为的类。考虑一下那个有意义的行为是不是应当迁移到已经存在或尚未发现的某个类中。p40 (21)我们在创建应用程序的分析模型时常常引入代理类。在设计阶段，我们常会发现特别多代理木有用的，应当去除。p43 (22)尽量减少类的协作者的数量。p52 1个类用到的其他类的数目应当尽量少。 (23)尽量减少类和协作者之间传递的消息的数量。p55 (24)尽量减少类和协作者之间的协作量，也即：减少类和协作者之间传递的不一样消息的数量。p55 (25)尽量减少类的扇出，也即：减少类定义的消息数和发送的消息数的乘积。p55 (26)假如类包含另1个类的对象，那么包含类应当给被包含的对象发送消息。也即：包含关系总是意味着用关系。p55 (27)类中定义的大多数方法都应当在大多数时间里用大多数数据成员。p57 (28)类包含的对象数目不应当超过开发者短期记忆的容量。这个数目常常是6。p57 当类包含多于6个数据成员时，可以把逻辑相关的数据成员划分为一组，之后用1个新的包含类去包含这一组成员。 (29)让系统（System）功能在窄而深的继承体系中垂直分布。p58 (30)在实现语义约束时，最好根据类定义来实现。这常常会导致类泛滥成灾，在这种情形下，约束应当在类的行为中实现，通常是在构造函数中实现，但不是必须如此。p60 (31)在类的构造函数中实现语义约束时，把约束测试放在构造函数领域所允许的尽量深的包含层次中。p60 (32)约束所依赖的语义信息假如常常改变，那么最好放在1个集中式的第3方对象中。p60 (33)约束所依赖的语义信息假如很少改变，那么最好分布在约束所涉及的各个类中。p60 (34)类必须知道它包含啥，可是不能知道谁包含它。p61 (35)共享字面范围(也就是被同1个类所包含)的对象相互之间不应当有用关系。p61 (36)继承只应被用来为特化层次结构建模。p74 (37)派生类必须知道基类，基类不应当知道关于它们的派生类的任何信息。p74 (38)基类中的全部数据都应当是私有的，别用保护数据。p75 类的设计者永远都不应当把类的用者不要的东东放在公有接口中。 (39)在理论上，继承层次体系应当深一点，越深越好。p77 (40)在实践中，继承层次体系的深度不应当超出1个普通人的短期记忆能力。1个广为接受的深度值是6。p77 (41)全部的抽象类都应当是基类。p81 (42)全部的基类都应当是抽象类。p82 (43)把数据、行为和/或接口的共性尽可能地放到继承层次体系的高端。p85 (44)假如2个或更多个类共享公共数据(但木有公共行为)，那么应当把公共数据放在1个类中，每一个共享这个数据的类都包含这个类。 p88 (45)假如2个或更多个类有共同的数据和行为(就是方法)，那么这类类的每1个都应当从1个表示了这类数据和方法的公共基类继承。 p89 (46)假如2个或更多个类共享公共接口(指的是消息，而不是方法)，那么仅有他们要被多态地用时，他们才应当从1个公共基类继承。 p89 (47)对对象类型的显示的分情形分析一般是错误的。在大多数这样的情形下，设计者应当用多态。p89 (48)对属性值的显示的分情形分析常常是错误的。类应当解耦合成1个继承层次结构，每一个属性值都被变换成1个派生类。 p96 (49)别通过继承关系来为类的动态语义建模。试图用静态语义关系来为动态语义建模会导致在运行时切换类型。p97 (50)别把类的对象变成派生类。对任何仅有1个实例的派生类都要多加小心。p99 (51)假如你觉得要在运行时刻创建新的类，那么退后一步以认清你要创建的是对象。目前，把这类对象概括成1个类。 p103 (52)在派生类中用空方法(也就是啥也不做的方法)来覆写基类中的方法应当是非法的。p103 (53)别把可选包含同对继承的要相混淆。把可选包含建模成继承会带来泛滥成灾的类。p108 (54)在创建继承层次时，试着创建可复用的框架，而不是可复用的组件。p112 (55)假如你在设计中用了多重继承，先假设你犯了错误。假如没犯错误，你要设法证明。p120 (56)只需要在面向对象设计中用到了继承，问自己2个问题：(1)派生类是不是是它继承的那个东东的1个特殊类型？(2)基类是不是派生类的一部分？p121 (57)假如你在1个面向对象设计中发现了多重继承关系，确保木有哪个基类实际上是另1个基类的派生类。p122 (58)在面向对象设计中假如你要在包含关系和关联关系间作出选取，请选取包含关系。p135 (59)别把全局数据或全局函数用于类的对象的薄记工作。应当用类变量或类方法。p140 (60)面向对象设计者不应当让物理设计准则来破坏他们的逻辑设计。可是，在对逻辑设计作出决策的过程中我们常常用到物理设计准则。 p149 (61)别绕开公共接口去修改对象的状态。p164 ———-Arthur J。Riel。

    • 如何理解设计模式、面向对象的设计模式这两个概念？

  • 完整问题：如何理解设计模式、面向对象的设计模式这两个概念？
  • 好评回答：设计模式一般来说指GOF23种设计模式，GOF设计模式就是面向对象设计中的常用模式。 所以没有区别哦

    • 面向对象编程的几个原则是什么？

  • 完整问题：面向对象编程的几个原则是什么？
  • 好评回答：1。 开闭原则（the Open Closed Principle OCP）一个模块在扩展性方面应该是开放的而在更改性方面应该是封闭的。因此在进行面向对象设计时要尽量考虑接口封装机制、抽象机制和多态技术。该原则同样适合于非面向对象设计的方法，是软件工程设计方法的重要原则之一。我们以收音机的例子为例，讲述面向对象的开闭原则。我们收听节目时需要打开收音机电源，对准电台频率和进行音量调节。但是对于不同的收音机，实现这三个步骤的细节往往有所不同。比如自动收缩电台的收音机和按钮式收缩在操作细节上并不相同。因此，我们不太可能针对每种不同类型的收音机通过一个收音机类来实现（通过重载）这些不同的操作方式。但是我们可以定义一个收音机接口，提供开机、关机、增加频率、降低频率、增加音量、降低音量六个抽象方法。不同的收音机继承并实现这六个抽象方法。这样新增收音机类型不会影响其它原有的收音机类型，收音机类型扩展极为方便。此外，已存在的收音机类型在修改其操作方法时也不会影响到其它类型的收音机。2。 替换原则 （the Liskov Substitution Principle LSP）子类应当可以替换父类并出现在父类能够出现的任何地方。这个原则是Liskov于1987年提出的设计原则。它同样可以从Bertrand Meyer 的DBC （Design by Contract） 的概念推出。我们以学生为例，夜校生为学生的子类，因此在任何学生可以出现的地方，夜校生均可出现。这个例子有些牵强，一个能够反映这个原则的例子时圆和椭圆，圆是椭圆的一个特殊子类。因此任何出现椭圆的地方，圆均可以出现。但反过来就可能行不通。运用替换原则时，我们尽量把类B设计为抽象类或者接口，让C类继承类B（接口B）并实现操作A和操作B，运行时，类C实例替换B，这样我们即可进行新类的扩展（继承类B或接口B），同时无须对类A进行修改。3。 依赖原则 （the Dependency Inversion Principle DIP）在进行业务设计时，与特定业务有关的依赖关系应该尽量依赖接口和抽象类，而不是依赖于具体类。具体类只负责相关业务的实现，修改具体类不影响与特定业务有关的依赖关系。在结构化设计中，我们可以看到底层的模块是对高层抽象模块的实现（高层抽象模块通过调用底层模块），这说明，抽象的模块要依赖具体实现相关的模块，底层模块的具体实现发生变动时将会严重影响高层抽象的模块，显然这是结构化方法的一个”硬伤”。面向对象方法的依赖关系刚好相反，具体实现类依赖于抽象类和接口。为此，我们在进行业务设计时，应尽量在接口或抽象类中定义业务方法的原型，并通过具体的实现类（子类）来实现该业务方法，业务方法内容的修改将不会影响到运行时业务方法的调用。4。 接口分离原则（the Interface Segregation Principle ISP）采用多个与特定客户类有关的接口比采用一个通用的涵盖多个业务方法的接口要好。ISP原则是另外一个支持诸如COM等组件化的使能技术。缺少ISP，组件、类的可用性和移植性将大打折扣。这个原则的本质相当简单。如果你拥有一个针对多个客户的类，为每一个客户创建特定业务接口，然后使该客户类继承多个特定业务接口将比直接加载客户所需所有方法有效。以上四个原则是面向对象中常常用到的原则。此外，除上述四原则外，还有一些常用的经验诸如类结构层次以三到四层为宜、类的职责明确化（一个类对应一个具体职责）等可供我们在进行面向对象设计参考。但就上面的几个原则看来，我们看到这些类在几何分布上呈现树型拓扑的关系，这是一种良好、开放式的线性关系、具有较低的设计复杂度。一般说来，在软件设计中我们应当尽量避免出现带有闭包、循环的设计关系，它们反映的是较大的耦合度和设计复杂化。
    • 版权声明

    作者：半米阳光

    分享生活常识,健康常识,饮食常识,母婴常识,教育常识，职场常识，民俗常识等各方面专业知识。

    相关推荐

    热门文章

    推荐文章

    最新文章