关于典型系统中名称空间和类命名的最佳实践，有很多很好的指南。

我正在对一个系统进行建模，该系统引入了可用指南未解决的问题(至少我找不到它)。该系统自然有几个共享相同名称的类。

为了简化，我将使用一个捕获问题本质的领域示例。

选项1：我可以使用名称空间和名称空间别名来区分代码中的类。类的命名无需担心整个命名空间之间的重复。

足球，进攻，战术

足球，防守，战术

使用进攻=足球。进攻。战术

使用防御=足球。防御。战术

{

Offensive.Play offensivePlay =新的Offensive.Play();

Defensive.Play defensivePlay =新的Defensive.Play();

}

选项1问题：

• 初级开发人员可能会感到困惑。
• 混淆会增加消耗名称空间的所有内容的开销。
• 如果不使用别名，则会使所有人混淆代码。

选项2：不要使用名称空间，而是将本质上是名称空间语义的类命名为类。 (进攻进攻和防守进攻)。

选项2问题：

• 潜在的长类名。例如：OffensivePresnapAdjustmentType

• 将名称空间语义嵌入类名称会导致
  重复的类名。

  • 进攻性基础比赛
  • 进攻构成
  • 进攻性比赛
  • 进攻玩家
  • 进攻包装
  • 进攻前调整
  • OffensivePresnapAdjustmentType
  • (还有"更多"以及所有防御性等效项。)
• 不太有效的智能感知(Visual Studio)

选项3：创建两个程序集-Football.Offense和Football.Defense。 (这与选项1相同，有可能实现更清晰的分离)

选项3问题：

• 与选项1相同的问题。
• 介绍多个程序集的复杂性。

我倾向于第一个或第三个选项，但是我没有足够的实践经验，无法知道在将来的版本中是否要做出决定导致大量乏味的名称空间和类名称重构。

我想设计名称空间并正确命名类，以经受多个主要版本的时间测试。

您对这种情况下的最佳做法有何看法？

您不是很了解我认为是名称空间的问题。

防守战术和进攻战术的表现实际上是不同类型的对象。

有些戏剧是防守战术，有些是进攻战术。 即 防守和进攻是比赛的属性，而不是相反。

命名空间只是组织单位。

您可以为文件加载器使用一个名称空间，为策略引擎使用另一个名称空间。

为什么不仅仅拥有一个带有play方法的IPlay接口……以及实现它们的某种战术类。 我不明白为什么您只需要名称空间或想要反转自然起作用的对象结构。

您正在尝试使更具体的内容在层次结构imo中占据更一般的位置。 因此，为什么您会感到痛苦。