我目前有一个类,可以在单个方法create()
中执行所有功能。
// Approach 1
class My_Class {
public function create() {
// Lots of code.
}
}
我想知道是否应该将create()
方法分解为多个较小的方法,如下所示:
// Approach 2
class My_Class {
public function create() {
$this->assemble();
$this->paint();
}
private function assemble() { // Code. }
private function paint() { // Code. }
}
方法assemble()
和paint()
非常专业(它们在我的项目中的任何其他地方都无法重复使用)。这让我想知道在我的情况下是否需要方法2。
我的问题:
有什么方法可以表明它应该分解成更小的方法?我试图了解何时应该模块化,什么时候不应该。
答案 0 :(得分:1)
实际原因,或者为什么可能有必要保留代码DRY,以及您希望将一种方法分解为不同的方法,如果这些方法当前或将来执行的操作可能是需要从对象的不同部分或其他对象(公共)调用。
除了上述情况之外,它在很大程度上是一个意见问题,我宁愿将事情分解为谨慎的方法,以在合理的程度上保持整洁,以便有一些语义故事可供您或其他开发人员阅读并明白。您可以阅读initialize(),assemble(),prime_surface(),paint(),End(),而不是阅读代码。后者讲述了一个更好的故事。
答案 1 :(得分:1)
没有官方指示何时应该将方法分解为多个方法,我仍然(我被迫)使用没有对象的代码,因此代码根本没有被隔离。不同之处在于您的课堂个人使用案例。如果您选择拆分main方法,则可以更轻松地记录业务逻辑的各个部分,而不是一次解释整个类。单元测试是另一个可以受益的组件,允许单独测试方法,允许测试更少依赖整个类。
就我个人而言,我尝试保持方法简短和分离,因为当你调用方法postForm($request, $dataMapper)
而不是阻塞代码块之后更清楚你的代码的意图是什么(并且分解那些代码块来看表单开始发布,表单发布结束的地方)。如果您需要调试代码,则可能需要阅读方法中的每个命令以查找错误。分离的代码可能会让您知道哪一段代码对错误负责,因为您可以为其指定一个适合业务逻辑上下文的名称。