属于另一个具有类似名称的类的属性的名称约定

我确信之前已经询问过此问题，但我无法找到任何相关答案 - 可能是因为我使用的术语的一般性质。属于另一个具有类似名称的类的属性的名称约定

我有一堂课 - 我们称之为Foo。现在给定的Foo具有定义它的性质的各种属性。为了争辩，我们称它们为Name,Inactive和Notes。 Foo也可以有许多种类，因为缺少一个更好的词，每个种类都是FooType。

所以，我们有下面的类定义：

public class FooType 
{ 
    public byte Id { get; set; } 
    public string Name { get; set; } 
    public bool Inactive { get; set; } 
    public string Notes { get; set; } 
} 

public class Foo 
{ 
    public Guid Id { get; set; } 
    public FooType TypeOfFoo { get; set; } 
    public string Name { get; set; } 
    public bool Inactive { get; set; } 
    public string Notes { get; set; } 
}

不完全理想的情况下，我知道了。不幸的是，FooType上的Inactive和Notes字段是必须的，所以我不能按我的意愿使用enum。我的窘境是，我无法找出TypeofFoo和FooType的合理描述性名称。称他们为TypeofFoo和FooType是丑陋的，并且在将来容易产生混淆，所以我正在寻找替代品。

是否有涵盖此的任何形式的命名约定？

来源

2015-02-17 Locke

'public FooType Type {get;组; }'或'public FooType FooType {get;组; ''？ – dotctor 2015-02-17 20:39:26

我对'Type'的关注是'System.Type'的潜在混淆。同样，'FooType'（属性）与'FooType'（类）混淆。为了记录，后者是我最初的样子。我是否在推翻它？ – Locke 2015-02-17 20:41:58

命名取决于上下文。名称应该表示它存储的内容。如果这是一个'帐户'说'帐户'。当你给像'FooType'这样无意义类型名称的例子时，你不能指望一个好的答案。我可以看到@dotctor已经给出了很好的答案。这就是说，你的问题是主观的，因此是题外话。 – 2015-02-17 20:42:09

不，没有命名约定。事实上，在.NET Framework本身并不能避免使用具有相同的名称作为自己的类型属性，甚至suggest it in some older guidelines：

SolidBrush.Color

Control.Font

这不是一个很简单的解决方案，并may cause confusion in certain edge cases like calling static members，但它并没有那么糟糕，有理由避免它断然。

来源

2015-02-17 20:50:08

我会尝试使用polymophy子类Foo并使用工厂的枚举FooType来创建对象。你的子类应该重写一般的方法来添加特定的行为。但我认为上下文对于选择正确的模式非常重要。只是使用一个特殊的命名在我看来是混乱的，并不代表你的意愿。

来源

2015-02-17 20:45:18 donmarkusi

属于另一个具有类似名称的类的属性的名称约定

回答

相关问题