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

Question

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

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

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

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

足球.进攻.战术

class Play { }

足球.防守.战术

Class Play { }

使用进攻 = Football.Offense.Tactics

使用防守 = Football.Defensive.Tactics

{

Offensive.Play进攻性Play = new Offensive.Play();

Defensive.Play defensivePlay = new Defensive.Play();

}

选项 1 问题：

• 可能会让初级开发人员感到困惑。
• 别名会增加任何消耗命名空间的开销。
• 如果不使用别名，每个人都会混淆代码。

选项 2：不使用命名空间，而是命名包含本质上命名空间语义的类。 （进攻性比赛和防守性比赛）。

选项 2 问题：

• 可能出现长类名。例如：OffensivePresnapAdjustmentType

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

  • OffensiveBasePlay
  • 进攻阵型
  • 进攻性比赛
  • 进攻型球员
  • 攻击性包
  • 进攻性Presnap调整
  • OffensivePresnapAdjustmentType
  • （还有更多，加上所有的防御等价物。）
• 智能感知效率较低 (Visual Studio)

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

选项 3 问题：

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

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

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

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

Answer 1

我认为你并不真正理解命名空间。

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

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

命名空间只是组织单位。

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

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

你试图让更具体的在层次结构中占据更一般的位置 imo。这就是为什么你会感到疼痛。