非典型系统中的命名空间和类命名最佳实践 [英] Namespace and Class Naming Best Practice in Atypical System
问题描述
在典型系统中有很多关于命名空间和类命名的最佳实践的指导。
There is a lot of good guidance out there on best practices for namespace and class naming in typical systems.
我正在建模一个系统，通过可用的指导（至少我不能找到它）。系统自然有几个类，它们将共享相同的名称。
I am modeling a system which introduces a problem not addressed by the available guidance (at least I am not able to find it). The system naturally has several classes which would share the same name.
为简化起见，我将使用一个捕获问题本质的域示例。
For simplification, I will use a domain example that captures the essence of the problem .
选项1：我可以使用命名空间和命名空间别名来区分代码中的类。类将被命名，而不必关注跨命名空间的重复。
Option 1: I could use namespace and namespace aliasing to differentiate the classes in code. Classes would be named without concern for duplication across the namespace.
Football.Offense.Tactics
Football.Offense.Tactics
class Play { }
Football.Defense.Tactics
Football.Defense.Tactics
Class Play { }
使用Offensive = Football.Offense.Tactics
using Offensive = Football.Offense.Tactics
使用Defensive = Football.Defensive.Tactics
using Defensive = Football.Defensive.Tactics
{
Offensive.Play offensivePlay = new Offensive.Play（）;
Offensive.Play offensivePlay = new Offensive.Play();
Defensive.Play defensivePlay = new Defensive.Play
Defensive.Play defensivePlay = new Defensive.Play();
}
选项1问题：
- 对初级开发者可能造成混淆。
- 别名添加任何消耗命名空间的开销。
- 如果不使用别名，则会对所有人造成混淆。
Option2：命名空间，类名合并了本质上是命名空间语义的类。 （OffensivePlay和DefensivePlay）。
Option2: Instead of using the namespace, name the class incorporating what are essentially namespace semantics. (OffensivePlay and DefensivePlay).
选项2问题：
- 类名。例如：OffensivePresnapAdjustmentType
-
将命名空间语义嵌入类名会导致
重复的类名。
- Potential for long classnames. Ex: OffensivePresnapAdjustmentType
Embedding namespace semantics into class names leads to repetitive class names.
- OffensiveBasePlay
- 进攻成功
- 攻击性玩法
- 进攻性玩家
- OffensivePackage
- OffensivePresnapAdjustment
- OffensivePresnapAdjustmentType
- （还有更多防御等效物。 ）
- OffensiveBasePlay
- OffensiveFormation
- OffensivePlay
- OffensivePlayer
- OffensivePackage
- OffensivePresnapAdjustment
- OffensivePresnapAdjustmentType
- (And Many More plus all of the defensive equivalents.)
选项3：创建两个程序集 - Football.Offense和Football.Defense。 （这与选项1相同，有可能更清晰地分离）
Option 3: Create two assemblies - Football.Offense and Football.Defense. (This is the same as option 1 with the potential for an even cleaner separation)
选项3问题：
- 与选项1相同的问题。
- 引入多个程序集的复杂性。
我倾向于第一个或第三个选项，但是我没有足够的实践经验来知道一个决定是否会在未来的版本中导致很多繁琐的命名空间和类名重构。
I am tending towards the first or 3rd option, but I don't have enough practical experience to know if a decision is going to lead to a lot of tedious namespace and class name refactoring in a future release.
我想要构建命名空间，并正确命名这些类以承受几个主要版本的时间测试。
I want to architect the namespace and properly name the classes to withstand the test of time over several major releases.
您对这种情况下的最佳做法有什么想法？
What are your thoughts on best practices in this situation?
推荐答案
您真的不了解命名空间我认为是问题。
You don't really understand namespaces I think is the problem.
在防守策略和进攻策略上的表现实际上是不同类型的对象。
How are plays in defensive tactics and offensive tactics actually a different type of object.
防守策略有些是攻击性的。也就是说
Some plays are defensive tactics some are offensive. I.e. defensive and offensive is a property of the play not the other way around.
命名空间只是组织单位。
您可以为文件加载器使用命名空间，为战术引擎使用另一个命名空间。
You may use a name space for a file loader and another for a tactics engine.
为什么不只是有一个播放方法的IPlay接口...和一些实现它们的战术类。我不明白为什么你想要命名空间，或者想要反转自然工作的对象结构。
Why not just have an IPlay interface with a play method... and some kind of tactics classes that implement them. I don't get why you want namespaces at all or want to invert the object structure that would naturally work.
你试图让更具体的占据位置在层次结构imo中更一般。因此，你为什么感到痛苦。
You are trying to make the more specific occupy the position of the more general in a hierarchy imo. Hence why you are feeling the pain.
这篇关于非典型系统中的命名空间和类命名最佳实践的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
