这只是一个意见问题，但我不想引起辩论。我只是想要专业的反馈，让你的类完成所有工作到你只需要实例化对象的地方是好的做法还是坏的做法。如果一切顺利，那么无论你的应用程序中的什么，你都可以在课堂上进行下一步。如果出现问题，您还可以创建一个函数来在类中发出错误。
我使用神奇的 __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 的真正强大之处不仅在于您可以在概念上捆绑函数（也可以使用包含概念相关函数的适当包含文件来完成），而且 OOP 的真正强大之处在于您可以将有用的子类化现有的类。
在我看来，如果您对 OOP 感到不舒服，请不要被迫完全采用 OOP。使用 OOP 完成的所有任务也可以使用过程方法完成。通常，对于更平凡的任务，程序方法的编程速度更快，并且与面向对象一样清晰。
这个问题的思路是“使用整数还是浮点更好”。好吧，这取决于情况。
什么 WORKS 和什么是“标准”是不一样的。如果您的方法有效，并且易于调试和维护，那么它是一个很好的解决方案。