Question

这是一个讨论而不是一个彻头彻尾的问题，因此我把它作为社区维基。你什么时候选择将方法分解为更小的方法。

假设我有一个有一个目的的方法，即加载配置文件

public function configure($file){
    $info = path_info(file);
    $ext = $info['extension'];

    switch($ext){
    case 'ini':
    //code to parse ini files
    break;

    case 'xml':
    //code to parse xml files
    break;

    case 'php':
    //code to parse php files
    break;
}

}

个人而言，我会根据转换的结果分析内部方法 - 但是说我有一个更顺序的方法，一系列步骤 - 即

public function doSequence(){
    $stepOne = //some database access to retrieve values
    $stepTwo = //the result of some interpretation of values
    $stepThree = //a fresh database interaction based on the interpreted values
    $stepFour = //prep values for return
    return $values
}

那么，将方法重构为适当的粒度级别的指导原则是什么？

Answer 1

我们重构的基本情况是：

重用：方法分解为方法m1，m2，m3，m4。其中m2和m4被重复使用。
可维护性：方法中的代码已经成长，很难维护。
逻辑分组：一种方法执行许多任务，并且它们在逻辑上是可分离的。将方法重构为具有与任务所代表的一样多的逻辑组。

此列表可能会更长。

Answer 2

根据经验：如果您用简单的英语描述您的方法并且描述包含AND，那么将该方法分解为更小的块是一个很好的候选者。基本上，一种方法应该在不到30s内可以理解。如果没有，重构。

在上面的示例中，解析配置文件的代码不应该在此方法内，甚至不应在同一个类中。 Ini File Parser有一个职责：解析ini文件。 YAML文件解析器解析YAML文件等。将实际的解析器分成不同的类。给他们一个界面。然后将解析器聚合到Config类中。

Answer 3

当你无法凭良心说明你完全完全它的作用时，你会重构一种方法。通常，这意味着它不能拥有比您一眼就能看到的更多的线条。调用几个做复杂事情的子程序是可以的，即使你不确切知道它们是如何做的 - 毕竟，这就是抽象的全部。好的描述性子程序名称在这里非常有用

Answer 4

就个人而言，我重构一种方法，使其尽可能原子化。

function loadFileAndSave()
{
   this.openFile("file name");
   this.removeLineBreaks();
   this.saveToDisk();
}

当以这种方式编码时，你几乎可以不使用低级文档，因为代码本身就能很好地读取。

Answer 5

这个问题看起来要复杂得多，而且涉及到整个软件设计，而不仅仅是你的例子。有很多关于软件设计的书籍，不能用段落来概括。

例如，在作为模型一部分的同一对象中进行数据库访问可能不是一个好主意。数据库访问可能被视为更多的技术服务，与程序的逻辑无关，因此可能需要一个单独的类（这有助于重用）。但这一切都取决于。

何时重构方法

5 个答案: