打破公有成员函数到大量的私有成员函数

当我写一个类的公共成员函数，做几件事情，如..打破公有成员函数到大量的私有成员函数

void Level::RunLogic(...);

在此功能，我发现自己分裂它分为几个私有成员函数。有多达分裂公共成员函数成几个功能，因为你不会做一两件事没有其他没有意义的，我不希望用户在什么样的顺序等。相反，在RunLogic（）函数会担心什么看起来像这样...

void Level::RunLogic(...) { 
DoFirstThing(); 
DoSecondThing(); 
DoThirdThing(); 
}

由于DoThing功能是私人成员功能。在Code Complete中，Steve McConnel建议减少一个类中的函数数量，但我宁愿不把所有代码都放到一个函数中。我认为他的真正含义是一个类不应该有太多的功能，但我只是想知道其他程序员对此有何看法。另外，我一直在寻求在公共成员函数中暴露越来越少的实现细节，并将大部分工作转移到小型私有成员函数中。显然这会产生更多的功能......但这就是问题所在。我用

来源

2009-12-17 Anonymous

一个规则是三个规则。如果我在不同的地方做了三次相同的事情，值得拥有一个单独的（可能是私有的）成员函数来封装共享的行为。

，我一般在这种情况下使用其他唯一的规则是，可读性。如果我正在查看在IDE中填充多个屏幕的成员函数，我发现很难追踪所有代码路径和可能的错误转向。在这种情况下，将一个整体成员函数分解为两个或更多个专用辅助函数是完全合理的。

关于代码关于类中函数数量的完整评论，请记住函数数量中涉及的最大风险主要与外部可用接口的复杂性有关。您提供给其他人使用的入口点越多，发生错误的可能性就越大（例如，由于其中一名公共成员的错误，输入错误等）。添加私有成员函数不会增加公共API的复杂性。

来源

2009-12-17 02:15:38

我建议将它们分解为单独的方法，其中每个方法负责一个小任务，并且对每个私有方法都有描述。打破方法和方法名称将使逻辑代码更具可读性！比较：

double average(double[] numbers) { 
    double sum = 0; 
    for (double n : numbers) { 
    sum += n; 
    } 
    return sum/numbers.length; 
}

到：

double sum(double[] numbers) { 
    double sum = 0; 
    for (double n : numbers) sum += n; 
    return sum; 
} 

double average(double[] numbers) { 
    return sum(numbers)/numbers.length; 
}

代码大全地址，每类公开的接口，而不是实现。

将这些较小的方法作为包保护可能更有意义，因此您可以轻松地对它们进行单元测试，而不是仅能够测试复杂的RunLogic。

来源

2009-12-17 02:16:45 notnoop

其实，我发现你的第一个例子更具可读性。减少阅读for循环的努力。我可以管理的连续四个陈述。 – 2009-12-17 12:43:19

你无意中遵循FF规则：

A class should have only one reason to change/Single responsibility principle

这是一件好事。通过恰当地分离责任，确保您的应用不会因为change

来源

2009-12-17 02:22:56 lemon

而不会轻易中断。您希望保持公共方法简单并将其功能分割为多个私有方法。

麦康奈尔是正确的，你应该减少你保持在一个类的方法数。

这两个目标并不完全相反。我不认为麦康奈尔会主张让你的功能更长，以减少它们的数量。相反，您应该考虑将一些私有方法推入一个或多个可供公共类使用的实用程序类。

完成此操作的最佳方式取决于您的代码的细节。

来源

2009-12-17 02:23:07 benzado

我同意分割功能。

我一直被教导并一直坚持着一个函数定义为执行单个封装的任务，如果它似乎是在做多件事情的知识，那么就可能重新因素它是可行的。然后是一个类将相似或相关的函数封装在一起。

拆分这些任务下来，仍然使用在我看来，一个公共成员允许类执行它的目的的方式，重要的任务，同时使其更容易维护。我还经常发现，在同一个复杂方法中有多个类似的代码段，可以通过参数重新分解为单个泛型函数 - 这既提高了可读性，又提高了可维护性;甚至可以减少代码量。

来源

2009-12-17 02:26:05

我看不出保持特别是公共成员函数尽可能小的优点（在代码行测量）。通常，长函数的可读性往往较差，因此在大多数情况下，传播大函数的实现可以提高可读性，无论它们是否属于类的一部分。

至于保持类尽可能小的好建议，这是接口的公共部分和封装的数据量尤为重要。原因在于具有大量数据成员和公共函数的类撤销了数据封装的优点。

来源

2009-12-17 08:07:57

一个，我用的是没有人的功能会比满屏幕空间更多的时间“经验法则”。尽管头脑简单，但它可以帮助您在“一次一屏”的情况下完成所有工作。它也会限制（根据定义）任何一种方法的复杂性。如果您希望将工作交给同事进行进一步维护，升级和错误修复（！），保持简单就很好。考虑到这一点，我同意保持简单的公共方法几乎总是正确的选择。

来源

2010-01-19 13:07:35 TheEruditeTroglodyte

打破公有成员函数到大量的私有成员函数

回答

相关问题