将顺序内聚转化为功能内聚？

与（仅）程序凝聚力是一个支撑不同的，可能不相关的活动，其中，控制从一个活动到下一个道次的模块。页 - 琼斯给出了（一个模块的例子，其名称可能是这样的，``准备节日大餐：“”

清洁用具从以前的膳食
准备土耳其烤
制作电话呼叫
采取淋浴
扒蔬菜
将表

现在的问题是，如果每个这些活动，即进行电话呼叫，提取到自己的方法，但它们仍然都被称为在相同的顺序即

private void PrepareForHolidayMeal() 
    { 
    CleanUtensilsfromPreviousMeal(); 
    PrepareTurkeyforRoasting(); 
    ... 
    SetTable(); 
    }

是这种方法仍然是一个例子程序凝聚力？还是它在功能上具有内聚性，因为它支持执行一个问题相关任务的活动，在这种情况下，准备吃饭？

来源

2012-10-15 x1886x

由于充分的原因，您的示例中的电话被省略。这是无关的任务之一。如果你认为电话仍然在“......”，那么整个事情就会再次失去凝聚力。否则，你可能会争辩说，所有其他活动都是准备膳食所必需的。这可能会开始讨论“CleanUtensilsfromPreviousMeal”在这里实际上是否有效，因为此活动可能仅在之前没有清理的情况下是必需的。 StackExchange的问题不适合这样的讨论......所以我们需要一个更清晰的例子来让决策得到多个软件架构师的同意。否则有些人可能会与其他人争辩不同。

来源

2012-10-17 18:07:10

我明白你的意思是关于cleanUtensils和makePhoneCall的有效性。我的问题的重点不在于与方法本身的实际内容有关，而在于主要的prepareHolidayMeal方法的结构。即假设所有的操作都是有效的和必要的，将它们移入他们自己的方法是否会将内聚的类型从程序变为功能？ – x1886x

凝聚力意味着“粘在一起” - 如果你解开它们，事情会更好。一旦你再次开始捆绑，你需要小心。您仍然可以创建至少有帮助的新捆绑包。后续问题可能是信息隐藏被破坏了。所以你需要一个很好的平衡。 –

这是一个非常有趣的问题，是的，答案是相对的，取决于我们理解[写在文章中]的方式以及它们与作者意思相对应的方式。

特别是程序性和功能性内聚之间存在一些细微差别：程序性内聚是包含彼此无关的步骤的东西，即对于程序来说没有“目标”，它是可重复的并且需要使它“固定定义“并重新使用。而功能内聚力基本上是一个功能（可能接受输入并给出输出），它可以用于不同的输入，并在重新使用时产生正确的输出（取决于输入）。

结论，根据你的问题：不，将每个方法放在不同的方法中，并按照相同的顺序调用它们不会将其从程序变为功能，除非你的过程成为一个真正具有某个“目标”的函数。

来源

2012-11-26 16:57:12 Tengiz

将顺序内聚转化为功能内聚？

回答

相关问题