将顺序凝聚力转化为功能凝聚力?

时间:2012-10-15 22:45:31

标签: architecture theory ooad cohesion

this website所述,

  

具有(仅)程序凝聚力的模块是支持不同且可能不相关的活动的模块,其中控制从一个活动传递到下一个活动。 Page-Jones给出了一个模块的例子(其名称可能类似于“准备假日餐:''

  • 上一餐中的清洁用具
  • 准备土耳其烤制
  • 拨打电话
  • 洗澡
  • 剁蔬菜
  • 设置表

现在我的问题是,如果这些活动中的每一个,即拨打电话,都被提取到他们自己的方法中,但所有活动仍以相同的顺序被调用 即

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

这种方法仍然是程序凝聚力的一个例子吗?或者它是否具有功能上的凝聚力,因为它支持执行一个与问题相关的任务的活动,在这种情况下准备一顿饭?

2 个答案:

答案 0 :(得分:1)

您的示例中遗漏了电话是有充分理由的。这是一项不相关的任务。如果您认为电话仍然在" ..."比整个事情再次失去它的凝聚力。否则你可能会说所有其他活动都是准备饭菜所必需的。这可能会开始讨论" CleanUtensilsfromPreviousMeal"在这里实际上是有效的,因为这个活动可能只在之前没有清理的情况下是必要的。 StackExchange问​​题不适用于这样的讨论...所以我们需要一个更清晰的例子来决定多个软件架构师的决定。否则有些人可能会争论不同于其他人。

答案 1 :(得分:1)

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

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

结论,根据你的问题:不,将每个方法放在单独的方法中并以相同的顺序调用它们不会将它从程序更改为功能,除非你的程序成为一个真正具有某些“目标”的函数。