Php 什么时候是创建子类的正确时间？

在一个很大的数据库类上工作，并且可能会变得更大，我开始编写许多与数据库的一个特定方面（用户、注释、页面等）相关的属性和方法，因此感觉是时候将数据库类分为几个类了，每个类都处理自己的方面，并且只有数据库类包含绝对核心功能

然而，这样做感觉就像是创建额外的类，处理

包括
和类似的内容，而不必付出任何代价。代码是相当可维护的，并且“划分”（通过注释）成正确的部分，而且“大”类不会损害性能

所以，我来问你们：在你们的观点和经验中，什么时候是合适的时间来划分子类？不仅仅是在这个特定的情况下，而是在一般情况下。
我选择方法和功能的逻辑分组。
这是正常的。我有50个模型处理各种数据（很多表）

通过遵循命名约定并使用自动加载器，可以轻松解决包含的问题

例如，我像这样调用我的所有类-ClassNameModel.php，并将它们放在一个特定的目录中

自动加载器的外观如下所示：

function customAutoloader($class_name){
    $file_name = $class_name . ".php";

    //Modelis
    if(substr($class_name, -5) === "Model"){
        if(is_readable("/models/" . $file_name)){
            require_once("/models/" . $file_name);
        }
        return;
    }
}

在主索引或配置或任何内容中：

spl_autoload_register('customAutoloader');

而且不再包括…
模型不应取决于您的数据库结构。模型本身甚至不应该意识到存在一个数据库。teresko，你不是把模型和控制器混淆了吗？无论如何，我使用ORM（红豆）层…模型处理业务逻辑。其中不变的是存储介质已切换。若您从SQL存储移动到NoSQL或开始使用外部RESTAPI，则不应重写模型。此外，如果您对模型使用ORM，那么就不可能为它编写单元测试（您不能单独测试它）。不，我的意思是我在模型中使用ORM，例如，
函数getUser（$id）{return ORM:：load（“users”，$id）；}
，但我仍然不明白您的意思。我是不是少了一封MVC的信？如果我切换到RESTAPI，那么如果不是模型，我应该重写什么？您应该只重写负责存储和检索域对象的。在您的示例中，您的代码与名为“ORM”的类紧密耦合，这使得它不稳定。无论如何，重点是：您并没有太多遗漏一封信，但在一个编写良好的模型中，域业务逻辑与数据库访问是不耦合的。