非典型系统中的命名空间和类命名最佳实践

Question

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

我正在建立一个系统，该系统引入了可用指南未解决的问题（至少我无法找到它）。系统自然有几个可以共享相同名称的类。

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

选项1：我可以使用命名空间和命名空间别名来区分代码中的类。将命名类而不关心命名空间中的重复。

Football.Offense.Tactics

class Play { }

Football.Defense.Tactics

Class Play { }

使用Offensive = Football.Offense.Tactics

使用Defensive = Football.Defensive.Tactics

{

Offensive.Play offensivePlay = new Offensive.Play（）;

Defensive.Play defensivePlay = new Defensive.Play（）;

}

选项1问题：

• 初级开发人员可能会感到困惑。
• 别名为消耗命名空间的任何内容添加开销。
• 如果不使用别名，则会让每个人都感到困惑。

选项2：不是使用命名空间，而是将包含本质上命名空间语义的类命名。 （OffensivePlay和DefensivePlay）。

选项2问题：

• 长期姓名的可能性。例如：OffensivePresnapAdjustmentType

• 将命名空间语义嵌入到类名中会导致 重复的班级名称。

  • OffensiveBasePlay
  • OffensiveFormation
  • OffensivePlay
  • OffensivePlayer
  • OffensivePackage
  • OffensivePresnapAdjustment
  • OffensivePresnapAdjustmentType
  • （还有更多，加上所有防守等值。）
• 效果较差的智能感知（Visual Studio）

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

选项3问题：

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

我正在倾向于第一个或第三个选项，但我没有足够的实践经验来了解决定是否会导致在将来的版本中进行大量繁琐的命名空间和类名重构。

我想构建命名空间并正确地命名类以经受几个主要版本的时间测试。

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

Answer 1

你真的不了解我认为是问题的命名空间。

防守战术和进攻战术中的游戏实际上是一种不同类型的对象。

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

命名空间只是组织单位。

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

为什么不使用带有播放方法的IPlay接口......以及实现它们的某种策略类。我不明白为什么你想要名称空间或想要反转自然会起作用的对象结构。

你正试图让更具体的人在层次结构imo中占据更一般的位置。因此，为什么你感到痛苦。