OO 设计 - 将特定于实例的函数与特定于类的函数分离答案

【问题标题】：OO Design - Separating Instance-specific functions from class-specific functionsOO 设计 - 将特定于实例的函数与特定于类的函数分离
【发布时间】：2012-05-29 18:20:24
【问题描述】：

给定一个在语义上应该是某种类型的对象的类，但也有多个操作来操作 on 自己类型的对象，最好的方法是什么（模式？）在这种情况下组织课堂？我发现当开发人员创建对象但以程序性思维方式思考时，这种情况很常见。

例子：

Class User {
  private m_userData;
  function User() {}
  function GetUserData() {}

  function KillAllUsers(){}
  function MaimAllUsers(){}
}

【问题讨论】：

你说的是静态方法吗？
我认为问题是 KillAllUsers 方法应该在 User 类中是静态的，还是应该在其他地方。

标签： oop design-patterns

【解决方案1】：

从您的描述中不是很清楚，但似乎“KillAllUsers”和“MainAllUsers”方法正在对一组用户进行操作。我建议创建一个自定义 UserCollection，将这些方法作为实例方法，或者将它们创建为静态并传入用户集合。在现代领域模型术语中，您将处理 UserRepository。

【讨论】：

【解决方案2】：

我宁愿将这两个目的分为一个 User 和一个 UserManager 类。 IMO 这提供了类应该做什么的更清晰的分离。

编辑：正如 Dunk 正确观察到的，应用程序中的实际名称不应该是 UserManager，而是更能描述其实际用途的名称。很多时候，您会为您将要使用的功能找到一个设计模式，因此类的名称将由该模式提供。这可能会导致诸如 UserRepository 或 UserFactory 之类的名称。

【讨论】：

不确定我是否称它为“UserManager”，但创建这些用户的代码负责杀死/伤害他们是有道理的。
管理器类不会必须成为创建工厂...如果您只想为每个应用程序强制执行一个用户管理器（这可能是合法的），那么拥有用户有一套静态函数也是合理的。
在谈论班级名称时，请从您的词汇表中删除单词管理器。类的名称应该描述其目的。经理只是垃圾场的另一个词。任何功能都适合那里。这个词是许多极其糟糕的设计的原因
Dunk：我同意 usermanager 的描述性不是很强，但我之所以选择这个名称是因为我看不到任何适合 KillAllUsers 和 MaimAllUsers 这两个函数的设计模式（存储库不会损坏...） .也许 Dewayne 实际上需要一个工厂类，在这种情况下，它将是一个 UserFactory。

【解决方案3】：

抽象出要对对象执行的操作，例如通过创建接口。然后您可以稍后担心如何提供实际逻辑的实现。

通常，在处理类型为 User 的对象集合时，不会是 User 本身来实现它，而是另一个对象，例如 UserService。如果绝对希望它在类级别可用，您可以定义一个返回接口类型和默认实现的静态方法。

【讨论】：

不确定您将在哪里进行有关创建界面的部分。这不会在 User 中创建静态方法或将其放在其他地方之间做出选择。
选择很明确：不要在 User 上使用静态方法。 Put在其他地方。如果您确实希望 User 上的它是某种静态的，最好在 User 上使用一个静态 getUserService 方法，该方法返回接口类型和默认实现。

【解决方案4】：

诸如 killAllUsers() 或 MaimAllUsers() 之类的方法仅将预期的操作封装为“什么”，其在交互方面的不完整信息，特别是“谁”。您可以 .kill() 或 .maim() 一个用户实例，但需要有人（JackTheReaper）打算对用户这样做，因此 kill() 和 maim() 是 JackTheReaper 和用户之间的交互， killAllUsers() 中的“All”表示的部分意图是 JackTheReaper 类如何管理所有用户的引用的责任。本质上，这里的技巧是将类型级别的功能抽象为实体之间的交互

【讨论】：