仅调用其他功能的功能。这是一个好习惯吗？

我目前正在处理一组报告，这些报告包含许多不同的部分（均需要不同的格式），并且我正在尝试找出构造代码的最佳方法。我们过去完成的类似报告最终都具有非常大的功能（超过200行），这些功能可以对报告进行所有数据处理和格式化，从而使工作流看起来像这样：

DataTable reportTable = new DataTable();
void RunReport()
{
    reportTable = DataClass.getReportData();
    largeReportProcessingFunction();
    outputReportToUser();
}

我希望能够将这些大功能分解为较小的块，但恐怕最终我将拥有数十个不可重用的功能，而类似的“在这里做所有事情”功能的唯一作用是调用所有这些较小的函数，如下所示：

void largeReportProcessingFunction()
{
    processSection1HeaderData();
    calculateSection1HeaderAverages();
    formatSection1HeaderDisplay();
    processSection1SummaryTableData();
    calculateSection1SummaryTableTotalRow();
    formatSection1SummaryTableDisplay();
    processSection1FooterData();
    getSection1FooterSummaryTotals();
    formatSection1FooterDisplay();

    processSection2HeaderData();
    calculateSection1HeaderAverages();
    formatSection1HeaderDisplay();
    calculateSection1HeaderAverages();
    ...
}

或者，如果我们更进一步：

void largeReportProcessingFunction()
{
    callAllSection1Functions();

    callAllSection2Functions();

    callAllSection3Functions();
    ...        
}

这真的是更好的解决方案吗？从组织的角度来看，我认为是这样（即，一切都比可能的组织得要好得多），但是就代码的可读性而言，我不确定（可能只调用其他函数的功能链很大）。

有什么想法吗？

这通常称为功能分解，如果正确完成，通常是一件好事。

同样，函数的实现应在单个抽象级别内。如果您采用largeReportProcessingFunction，那么它的作用是定义按照哪个顺序执行哪些不同的处理步骤。所有这些步骤的实现都在下面的抽象层上，largeReportProcessingFunction不应直接依赖于此。

请注意，这是一个不好的命名选择：

void largeReportProcessingFunction() {
    callAllSection1Functions();
    callAllSection2Functions();
    callAllSection3Functions();
    ...        
}

您会看到callAllSection1Functions一个实际上并没有提供抽象的名称，因为它实际上并没有说出它是做什么的，而是说它是如何实现的。应该调用它，processSection1或者在上下文中实际上有意义的任何东西。

您说您正在使用C＃，所以我想知道您是否可以利用您使用的是面向对象的语言来构建结构化的类层次结构？例如，如果有必要将报告分为几个部分，请创建一个Section类并将其扩展以满足客户的特定要求。

考虑一下它就像创建非交互式GUI一样有意义。考虑一下您可能创建的对象，就像它们是不同的GUI组件一样。问自己，基本报告是什么样的？复杂的怎么样？扩展点应该在哪里？

这取决于。如果您创建的所有功能确实是一个单一的工作单元，那么很好，如果它们只是调用功能的第1-15、16-30、31-45行是不好的。长函数不是邪恶的，如果它们做一件事情，如果您的报表有20个过滤器，并且具有一个验证函数，该函数将检查所有20个过滤器将变长。很好，按过滤器或过滤器组将其分解只是增加了额外的复杂性而没有真正的好处。

拥有大量私有功能也使自动单元测试变得更加困难，因此一些人会尝试避免这种原因，但是我认为这是一个很差的理由，因为它倾向于创建更大，更复杂的设计来适应测试。

由于您正在使用C＃，因此请尝试在对象中进行更多思考。看起来您仍在通过后续函数依赖的“全局”类变量来进行程序编码。

在单独的功能中分解逻辑绝对比在单个功能中包含所有逻辑更好。我敢打赌，通过将功能分解为几个对象，还可以分离出函数要处理的数据。

考虑使用一个ReportBuilder类，您可以在其中传递报告数据。如果您可以将ReportBuilder分成单独的类，则也可以这样做。

是。

如果您有需要在多个地方使用的代码段，请使用自己的函数。否则，如果必须更改功能，则需要在多个位置进行更改。这不仅增加了工作量，而且还增加了错误发生的风险，因为代码在一个地方而不是在另一个地方或在一个地方被引入但在另一个地方而不是另一个地方被更改。

如果使用描述性方法名称，它也有助于使该方法更具可读性。

您使用编号来区分功能的事实表明，重复或类执行过多操作存在潜在的问题。将大型功能分解为许多较小的功能可能是重构重复项的有用步骤，但它不应该是最后一个。例如，您创建两个函数：

processSection1HeaderData();
processSection2HeaderData();

用于处理节标题的代码中没有相似之处吗？您可以通过参数化差异来为它们提取通用功能吗？

即使不重用子功能，将功能分解为逻辑子功能也是有帮助的–将其分解为简短易懂的块。但这必须由逻辑单元完成，而不仅仅是n＃行。您应该如何分解它取决于您的代码，常见的主题是循环，条件，对同一对象的操作。基本上任何您可以描述为离散任务的内容。

因此，是的，这是一种很好的样式-听起来很奇怪，但是鉴于您描述的重用有限，我建议您仔细考虑ATTEMPTING重用。确保用法是完全相同的，而不仅仅是偶然的相同。尝试处理同一块中的所有情况通常是您最终在第一时间获得大量笨拙功能的原因。

我认为这主要是个人喜好。如果您的函数将被重用（并且您确定不能使它们更通用和可重用？）我肯定会说拆分它们。我还听说过，这是一个很好的原则，即任何函数或方法中都不应包含超过2-3个屏幕的代码。因此，如果您的大型函数不断运行，则可能会使您的代码更具可读性以将其拆分。

您不会提及正在使用哪些技术来开发这些报告。看来您可能正在使用C＃。那是对的吗？如果是这样，如果您不想将函数拆分为较小的函数，则也可以考虑使用#region指令作为替代。