Namespace and Class Naming Best Practice in Atypic

问题:

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 .

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

class Play { }

Football.Defense.Tactics

Class Play { }

using Offensive = Football.Offense.Tactics

using Defensive = Football.Defensive.Tactics

{

Offensive.Play offensivePlay = new Offensive.Play();

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

}

Option 1 Problems:

• Potentially confusing for junior developers.
• Aliasing add overheads for anything which consumes the namespace.
• If aliasing is not used, confusing code for everyone.

Option2: Instead of using the namespace, name the class incorporating what are essentially namespace semantics. (OffensivePlay and DefensivePlay).

Option 2 Problems:

• Potential for long classnames. Ex: OffensivePresnapAdjustmentType

• Embedding namespace semantics into class names leads to repetitive class names.

  • OffensiveBasePlay
  • OffensiveFormation
  • OffensivePlay
  • OffensivePlayer
  • OffensivePackage
  • OffensivePresnapAdjustment
  • OffensivePresnapAdjustmentType
  • (And Many More plus all of the defensive equivalents.)
• Less effective intellisense (Visual Studio)

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)

Option 3 Problems:

• Same problems as option 1.
• Introduce the complexity of multiple assemblies.

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?

回答1:

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.

Namespaces are simply organisational units.

You may use a name space for a file loader and another for a tactics engine.

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.

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.