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

Question

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

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

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

选项1:我可以使用命名空间和名称空间别名来区分代码中的类。类的命名不考虑跨命名空间的重复。

Football.Offense.Tactics

class Play { }

Football.Defense.Tactics

Class Play { }

使用攻击性= Football.Offense.Tactics

使用防御性= Football.Defensive.Tactics

{

Offensive.Play offensivePlay =新Offensive.Play()；

Defensive.Play defensivePlay =新Defensive.Play()；

}

备选案文1问题：

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

Option2:而不是使用名称空间，命名包含本质上是名称空间语义的类。(OffensivePlay和DefensivePlay)。

备选案文2问题：

• 潜在的长类名。例: OffensivePresnapAdjustmentType
• 将命名空间语义嵌入到类名中会导致重复的类名。

- OffensiveBasePlay
- OffensiveFormation
- OffensivePlay
- OffensivePlayer
- OffensivePackage
- OffensivePresnapAdjustment
- OffensivePresnapAdjustmentType
- (And Many More plus all of the defensive equivalents.)  

​

• 不太有效的intellisense (Visual )

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

备选方案3问题：

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

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

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

你对这种情况下的最佳做法有什么看法？

Answer 1

您并不真正理解名称空间，我认为这就是问题所在。

防守战术和进攻战术中的战术实际上是不同类型的目标。

有些战术是防守战术，有些是进攻战术。也就是说，防守和进攻是游戏的一种属性，而不是相反。

名称空间只是组织单位。

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

为什么不拥有一个带有播放方法的IPlay接口..。以及一些实现它们的战术类。我不明白为什么您想要名称空间，或者想要反转自然工作的对象结构。

你在努力使更具体的职位在国际海事组织中占据更一般的地位。所以你才会感到痛苦。