将“fA()”和“fB()”重构为“fAB(){return report;}”的可维护性问题答案

【问题标题】：Maintainability issue of refactoring "fA()" and "fB()" to "fAB(){return report;}"将“fA()”和“fB()”重构为“fAB(){return report;}”的可维护性问题
【发布时间】：2017-02-01 08:01:55
【问题描述】：

当我的程序还很年轻的时候，通常会有很多功能做简单的事情。

等老了，发现把一些类似的函数捆绑在一起比较方便，把老函数的返回结果组合成一个“报表”。

“报告”可以作为不同模块之间的通信包轻松传递。

示例 1

代码 V1

class B{
    float getWidth(C c){ 
        float width= ... (very cheap function about "c") ;
        return width;
    }
    float getHeight(C c){
        float height= ... (very cheap function about "c") ;
        return height;
    }
};

代码 V2

class ReportSize { float width; float height; }
class B{
    ReportSize getSize(C c){   //<-- grouped
        float width = ... ;
        float height= ... ;
        return ReportSize(width ,height);
    }
};

示例 2

代码 V1

class D{
    Vector3 calculateNarrow(){ ... }
    Vector3 calculateBoard(){ ... }
};

代码 V2

class ReportVector3Pair{
    Vector3 resultNarrow;
    Vector3 resultBoard;
    Vector3 get(NARROW_OR_BOARD paramEnum){
        //return "resultNarrow" or "resultBoard"
    } 
};
class D{
    ReportVector3Pair calculate(){ ... }  //<-- grouped
};

问题

重构花费了一些开发时间。所有代码位置（最多 100 个调用者）都必须手动重构以匹配新签名。

如何最小化以后需要重构的机会？如果将来可能发生重构，如何最小化成本？

【问题讨论】：

我推荐这本书 Clean Code: A Handbook of Agile Software Craftsmanship (by Robert C Martin)（请注意，此链接仅引用了一个 PDF，其中只有几个免费示例章节 - 完整的书可在优秀的书店或在线供应商处获得）
如果宽度/高度对是你经常传递的东西，那么声明一个类型并不是一个糟糕的计划。我会使用struct 而不是class，因为这意味着它只是一个基本结构，没什么特别的。第二个例子看起来很奇怪，但也许额外的上下文将有助于澄清。抽象是您申请的原因，而不仅仅是因为。
@Christoph Bimminger 是哪一章或该章的名称是什么？

标签： c++ architecture maintainability

【解决方案1】：

如何尽量减少以后需要重构的机会？

创建可以返回更高级别对象而不是更改现有类的非成员函数。

例如，不要写B的V2，而是保留现有的B并使用：

class ReportSize { float width; float height; }
ReportSize getReportSize(B const& b, C c)
{
   return {b.getWidth(c), b.getHeight(c)}
}

同样，不要创建 D 的 V2，而是保留现有的 D 并使用：

Vector3 calculate(D const& d, NARROW_OR_BOARD paramEnum) {
   //return "resultNarrow" or "resultBoard"
}

如果将来可能发生重构，如何最小化成本？

使用非成员函数来扩展功能而不是修改现有类。

据 Scott Meyers 称，using non-member functions improves encapsulation.

使用非成员函数添加新功能也遵循The Open/Closed Principle。

【讨论】：