这只是一个意见问题，但我不想引起争论。我只想得到专业的反馈，让你的类把所有的工作都做到你只需要实例化对象的地方，这是好的做法还是坏的做法。如果一切顺利，那么无论应用程序中是什么，都可以在类中执行下一步。如果出现问题，您可以创建一个函数来同时在类中发出错误。
我用magic__construct方法完成了所有这些，并且我的所有属性都是私有的（或者如果我需要扩展一些东西，则受保护）。。。除了getter和setter之外，我的大多数方法都是私有/受保护的，因为所有事情都发生在类内部，所以我不怎么使用它们。
例如，我有一个登录类，当你实例化它时，你只需向它提供用户名和密码参数，__construct就会发生一切，我不需要使用该类对我的脚本做任何事情。而且和我的注册班一样。。您只需再次向它提供参数，该类就可以完成所有操作。我根本不需要用脚本操纵我的类。
好的做法还是坏的做法？我想成为一名专业人士，我想像这样开始编码，但也许我做得好吗？
我投票决定结束这场辩论，因为这可能会引发一场相对无用的辩论。
无论如何，关于构造器有两大理论：单阶段理论和多阶段理论。你在做单舞台表演。许多人主张单一舞台。然而，我认为这是不好的做法。为什么？
因为这会使测试更加困难。编写测试时，您希望测试对象的各个功能。。但是，如果您的构造函数执行所有操作，那就不可能了。
这也使得以后为了不同的目的重用对象变得更加困难。除了构造函数中的一个额外方法调用之外，您的对象可能会做您需要它做的一切——所以现在您必须稍微重写它，并至少在几个地方更改它的调用方式。
真正的答案是在项目范围内做你最满意的事情。
方法__construct应该只实例化（验证/准备用于实例化的值）对象，而不实例化其他对象。仅此而已。类在构造函数中完成所有工作是不合乎逻辑的。
编辑：良好实践：
Application app = new Application(context); // create application
app.run(); // run it
不良做法：
new Application(context) // create & run application
[只有我的2美分]
老实说，你还不如为你描述的东西使用一个函数。
在我看来，您正在使用类作为函数/功能的集合。
这是可以的，它使您的代码更加结构化，但您并没有真正使用OOP的功能。
OOP的真正力量不仅在于你可以在概念上捆绑函数（这也可以通过包含概念相关函数的适当include文件来实现），而且OOP的真实力量更多地在于你可以对有用的现有类进行子类化。
在我看来，如果你对OOP感到不舒服，不要觉得被迫去做OOP。所有用OOP完成的任务也可以用程序化的方法来完成。通常，对于更普通的任务，程序化方法编程更快，而且和面向对象的方法一样清晰。
这个问题的思路是"使用整数还是浮点更好"。好吧，这取决于情况。
什么是有效的和什么是"标准"是不一样的。如果您的方法有效，并且易于调试和维护，那么它是一个很好的解决方案。