水木上一个人问的关于OO原则的问题,其中涉及到高内聚与松耦合之间的细节区分的内容。
发信人: jamen (*******), 信区: SoftEng
标 题: 问个概念问题
发信站: 水木社区 (Fri Feb 5 13:42:31 2010), 站内
A team of programmers is reviewing a proposed API for a new utility class. A
fter some discussion, they realize thatthey can reduce the number of methods
in the API without losing any functionality. If they implement the new
design,which two OO principles will they be promoting?
A. Looser coupling
D. Higher cohesion
F. Stronger encapsulation
我也不知道正确答案有几个,想不明白
发信人: lilax (阿香), 信区: SoftEng
标 题: Re: 问个概念问题
发信站: 水木社区 (Fri Feb 5 14:30:18 2010), 站内
F肯定有
D不大清楚,如果就这三个里面选的话,就选DF吧
发信人: jamen (*******), 信区: SoftEng
标 题: Re: 问个概念问题
发信站: 水木社区 (Fri Feb 5 14:33:14 2010), 站内
呵呵晕了,刚在另外一个地方问,一哥们儿说选AD
发信人: lilax (阿香), 信区: SoftEng
标 题: Re: 问个概念问题
发信站: 水木社区 (Fri Feb 5 14:58:40 2010), 站内
我不确定,你再问别人吧
好像AF也没什么不可能
发信人: qingrun (青润), 信区: SoftEng
标 题: Re: 问个概念问题
发信站: 水木社区 (Fri Feb 5 15:11:32 2010), 站内
这个问题就是说原来有一个类,经过分析后发现,可以减少一些类中的方法,而类的设计功能不变
。
而减少了方法后的类,必然是提高了类内部的聚合能力,所以D的可能性很大。
这里只提到了类的问题,没有提到与其它模块之间的连接关系如何实现,是否因此需要原来的类内
多个方法调用用一个方法完成,所以,无法确定是否一定实现了A。因此A不确定。
同理,F也有可能,但是,也不好确定是否一定有它,因为这段内容对类的实现没有说出具体的设
计改变的方法。
发信人: Slimxp (爱上技术), 信区: SoftEng
标 题: Re: 问个概念问题
发信站: 水木社区 (Fri Feb 5 15:56:03 2010), 站内
A D吧,低耦合高汇聚,这不是OO软工里面一直提倡的吗?
发信人: zhangmike (克强总~~~~~~~~~~~~~~理不是偶), 信区: SoftEng
标 题: Re: 问个概念问题
发信站: 水木社区 (Fri Feb 5 22:07:54 2010), 站内
B,C,E等有没有啊?
发信人: qlw (钱五哥), 信区: SoftEng
标 题: Re: 问个概念问题
发信站: 水木社区 (Fri Feb 5 22:47:22 2010), 站内
可能D、F适用,减少API就意味着需要在接口中包含更多功能,则封装更多;
同时对模块设计来说,内聚性更强。
发信人: qingrun (青润), 信区: SoftEng
标 题: Re: 问个概念问题
发信站: 水木社区 (Fri Feb 5 22:58:13 2010), 站内
F的描述也不是很多,A的可能性不大,D的可能性最大。
发信人: jamen (*******), 信区: SoftEng
标 题: Re: 问个概念问题
发信站: 水木社区 (Sat Feb 6 03:53:56 2010), 站内
有这样一种想法:想像两个场景,封装的都很好,一种是松耦合一种是紧耦合,显然紧
耦合需要提供更多的API来支持耦合。
这样一想,是不是松耦合也有可能了?
发信人: qingrun (青润), 信区: SoftEng
标 题: Re: 问个概念问题
发信站: 水木社区 (Sat Feb 6 14:42:10 2010), 站内
OO原则中提到的是松耦合,高内聚.
内聚性只需要看这个接口或者类的内部设计的情况即可,而耦合是类间关系,没有直接的类间关系
的描述,所以,这个问题中不好说耦合度的变化问题。原题目内容较少,这方面是没法判断的。
发信人: jamen (*******), 信区: SoftEng
标 题: Re: 问个概念问题
发信站: 水木社区 (Sun Feb 7 00:43:53 2010), 站内
呵呵,好的,多谢了
【 在 qingrun (青润) 的大作中提到: 】
: OO原则中提到的是松耦合,高内聚.
: 内聚性只需要看这个接口或者类的内部设计的情况即可,而耦合是类间关系,没有直接的类间关
系的描述,所以,这个问题中不好说耦合度的变化问题。原题目内容较少,这方面是没法判断的。
分享到:
相关推荐
在本文中,我们探讨了软件包级别(即,面向对象(OO)系统中软件功能分解的最基本级别之一)中的耦合和内聚度量,目的是研究它们与每个软件包的技术债务之间的关系。 TD测量的当前最先进的工具正在源代码级别上工作...
高内聚、高耦合 D.低内聚、高耦合 2、在UML中,( )把活动图中的活动划分为若干组,并将划分的组指定给对象,这些对象必须履行该组所包括的活动,它能够明确地表示哪些活动是由哪些对象完成的。 A.组合活动 B...
掌握内聚度和耦合度的概念 掌握面向对象设计原则
面向对象设计(OOD)是面向对象编程(OOP)必不...单一职责原则可以看作是高内聚、低耦合在面向对象原则上的引申。类的职责过多,容易导致类间职责依赖,提高耦合度,降低内聚性。通常意义下的单一职责,指的是类只有一
1. 用例(Use case)用来描述系统对事件作出响应时所采取的行动。用例之间是具有相关性的。在一个“订单输入子系统”中,创建新订单和更新订单都需要核查用户帐号是否... 高内聚、高耦合的特征 D. 低内聚、高耦合的特征
面向对象系统的分析和设计实际上追求的就是两点,一是高内聚(Cohesion),而是低耦合(Coupling)。这也是我们软件设计所准求的,因此无论是OO中的封装、继承、多态,还是我们的设计模式的原则和实例都是在为了这两...
大家围绕着如何OO,如何高内聚低耦合,如何反转控制等话题进行了“热烈”的争论。照这样开下去,这个评审会岂不是变成了“神仙大会”!怎样的设计才叫优秀的设计呢?某项目的设计文档评审会上,各路技术大牛进行了...
17.14 高内聚 17.15 参考资料 第18章 使用GRASP的对象设计示例 18.1 什么是用例实现 18.2 制品注释 18.3 下一步工作 18.4 NextGen迭代的用例实现 18.5 Monopoly迭代的用例实现 18.6 过程:迭代和进化式对象...
17.14 高内聚 17.15 参考资料 第18章 使用GRASP的对象设计示例 18.1 什么是用例实现 18.2 制品注释 18.3 下一步工作 18.4 NextGen迭代的用例实现 18.5 Monopoly迭代的用例实现 18.6 过程:迭代和进化式对象...
17.14 高内聚 17.15 参考资料 第18章 使用GRASP的对象设计示例 18.1 什么是用例实现 18.2 制品注释 18.3 下一步工作 18.4 NextGen迭代的用例实现 18.5 Monopoly迭代的用例实现 18.6 过程:迭代和进化式对象...
17.14 高内聚 17.15 参考资料 第18章 使用GRASP的对象设计示例 18.1 什么是用例实现 18.2 制品注释 18.3 下一步工作 18.4 NextGen迭代的用例实现 18.5 Monopoly迭代的用例实现 18.6 过程:迭代和进化式对象...
17.14 高内聚 17.15 参考资料 第18章 使用GRASP的对象设计示例 18.1 什么是用例实现 18.2 制品注释 18.3 下一步工作 18.4 NextGen迭代的用例实现 18.5 Monopoly迭代的用例实现 18.6 过程:迭代和进化式对象...
17.14 高内聚 17.15 参考资料 第18章 使用GRASP的对象设计示例 18.1 什么是用例实现 18.2 制品注释 18.3 下一步工作 18.4 NextGen迭代的用例实现 18.5 Monopoly迭代的用例实现 18.6 过程:迭代和进化式对象...
17.14 高内聚 17.15 参考资料 第18章 使用GRASP的对象设计示例 18.1 什么是用例实现 18.2 制品注释 18.3 下一步工作 18.4 NextGen迭代的用例实现 18.5 Monopoly迭代的用例实现 18.6 过程:迭代和进化式对象...
17.14 高内聚 17.15 参考资料 第18章 使用GRASP的对象设计示例 18.1 什么是用例实现 18.2 制品注释 18.3 下一步工作 18.4 NextGen迭代的用例实现 18.5 Monopoly迭代的用例实现 18.6 过程:迭代和进化式对象...
架构原则很简单,即在高内聚,低耦合,可扩展,易理解大的指导思想下,尽可能的贯彻OO的设计思想和原则。如果你觉得Halo不错,让你很爽,烦请拨冗**“Star”**。Halo Framework,光环框架是基于DDD+CQRS+扩展点+业务...