我目前有一个类，它在单个方法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在我的情况下是否有必要。
我的问题：
一个方法是什么，表明它应该被分解成更小的方法？我试图理解什么时候应该模化，什么时候不应该模化。
如果你想让代码保持DRY，你想把一个方法分解成不同的方法的实际原因，或者说为什么有必要，是因为这些方法当前或将来执行的操作可能需要从对象或其他对象（公共）的不同部分调用。
除了上述情况之外，这在很大程度上是一个意见问题，我更喜欢在合理的程度上将事情分解为谨慎的方法，以保持事情的整洁，这样你或其他开发人员就可以阅读和理解一些语义故事。读取initialize（）、assembly（）、prime_surface（）、paint（）、the End（），而不是读取代码代码。后者告诉了一个更好的故事。
没有官方指示何时应该将一个方法分解为pieces，我仍然（被迫）使用没有对象的代码，因此代码根本没有被隔离。区别在于你在课堂上的个人用例。如果您选择拆分主方法，那么记录业务逻辑的部分内容比一次解释整个类更容易。单元测试是另一个可能受益的组件，允许将方法与其他方法分开测试，可以减少测试对整个类的依赖。
就我个人而言，我尽量保持方法的简短和分离，因为当你调用方法postForm($request, $dataMapper)而不是一个接一个的代码块时，你的代码的意图会更清楚（并删除这些代码块，看看表单的发布从哪里开始，表单的发布在哪里结束）。如果您需要调试代码，您可能需要读取方法中的每个命令来查找错误。分离的代码可能会让你知道哪段代码是bug的罪魁祸首，因为你可以给它一个适合业务逻辑上下文的名称。