OOP：应该在相关对象/类中封装多少程序逻辑作为方法？

我有一个简单的程序，可以有一个管理员用户或只是一个普通用户。 该程序还有两个类：for UserAccount和AdminAccount。 管理员需要做的事情（用例）包括添加帐户、删除帐户等等

我的问题是，我是否应该尝试将这些用例封装到对象中

只有使用AdminAccount登录的管理员才能添加和删除其他帐户。我可以有一个无类的子过程，将新的UserAccount对象添加到系统中，并在管理员按下“添加帐户”按钮时调用。或者，我可以将该过程作为方法放在AdminAccount对象中，并让button事件执行一些代码，如“Admin.AddUser（name，password）。”

---

我更倾向于选择第一个选项，但我不确定OO业务应该走多远。

创建帐户当然是一项业务活动，因此它应该是您的一个业务类（例如帐户）的一部分，而不是按钮方法中的逻辑。

对象中应该有多少逻辑

所有这些

面向对象101会说您应该有一个Account类。用户和管理员是两个角色，它们之间的权限可能有所不同，但在系统中添加和删除帐户的行为不应改变

您的对象所表达的使用超出了用户看到的界面，这也是事实。对于文本或图形用户界面，您的用例应该是可执行的。这是一个很好的测试，看看您将用户界面与逻辑分离得有多好，首先看看您是否可以在没有GUI的情况下解决问题

---

如果你先考虑GUI，那你就错了。

如果我有一个模块，其中包含对象管理过程，按钮/UI可以访问，但它本身不是一个类（或它管理的类的一部分），该怎么办？该过程可以将Dim X称为New UserAccount（name，password），从而调用UserAccount对象的构造函数，或者按钮单击事件代码可以调用admincount.AddUserAccount（name，password）方法，在这种情况下，我将通过一个对象创建另一个对象的新实例。这是正确的OOP实践吗？我相信如果你问一百万人这个问题，你会得到一百万个不同的答案。在我看来，使用最接近现实生活的模型。如果只有管理员可以创建帐户，那么admin.CreateUser（用户名、密码）感觉很自然（至少对我来说是这样）。我见过的另一种常见方法是静态方法，它接受用户（例如admin），比如so Account.CreateAccount（creatingUser、newUserName、newUserPassword）。CreateAccount方法将验证创建用户是否是管理员。这对我来说不是什么“OO”，但（…续）对于在数据库中定义一组角色，但没有为每个角色定义单独的角色类的应用程序很有用。我觉得这个方法也很合理。谢谢。这很有帮助。我同意你的第一个建议；是的，我想避免的一件事是在VB窗体/事件中添加任何重要的代码。但是，可以选择将所有方法封装在对象中，或者将重要的对象管理/业务逻辑过程集中在一个地方（例如模块）。到目前为止，我收到的建议似乎倾向于将所有逻辑放在对象/类中，因此系统完全是面向对象的。