类的前缀/后缀

Question

当你编写一个包含大量类的应用程序时，你是否为你的类名使用前缀/后缀？或者我应该只依赖我已定义的名称空间？

就我而言，我的课程如下：

Blur
Contrast
Sharpen
Invert
...

我只是不知道明天会发生什么，并希望尽可能与BCL中经常使用的类无碰撞。

有什么想法吗？

Answer 1

命名空间的发明正是为了解决这个问题。使用它们。

Answer 2

我会说不要使用前缀或后缀作为名称 - 这非常接近匈牙利符号，这被广泛认为是坏的，即使是MS的创建者也是如此。这个规则的唯一例外是接口，许多人认为可以使用I作为前缀，但我认为接口也不应该有前缀。您应该将与命名空间相关的类分组以防止冲突。

Answer 3

除非：

，否则请避免使用前缀或后缀类

• 这是一个界面：IFilter
• 您需要告知其参与模式：GaussianBlurStrategy
• （来自marc_s）您创建了一个自定义例外：ImageDoesNotSupportFilterTypeException
• 有时，如果某个内容是抽象基类，则进行通信：FilterBase

我被最后一个撕裂了。我不喜欢看到Base后缀，但是对于API的消费者而言，要知道他们无法根据名称实例化Filter（不先尝试），这真的很难。我不喜欢它，但这是我使用的惯例。

修改

根据Jon B的评论，使用Handler后缀自定义代理很常见（FilterExecutedHandler(object sender, FilterEventArgs e);）。虽然委托声明本身不是一个类，但它可能导致名称冲突，所以应该在这里说明。

Answer 4

通常，我会将它们命名为描述性内容（就像您所说的那样），但我将它们分成适当命名的命名空间。

在你的情况下，我会像

那样

namespace AppName.ImageOperations
{
    public class Blur{...}
}

Answer 5

如果你有一个公共基类或接口（例如类效应或接口IEffect），那么我可能会使用Effect作为这些类的后缀。

否则我倾向于使用命名空间。

Answer 6

在工作中，我们为所有类使用前缀，而某些类使用后缀。这确实阻止了BCL的碰撞，但在我看来这是不必要的。你最好使用合理的命名和良好的命名空间。

我建议在接口上使用I前缀，但这只是个人偏好。

Answer 7

实际上我不太关心前缀/后缀以及更多关于命名空间分区和类名的信息。我希望类名有意义，但我也想要正确的命名空间，以避免冲突并统一我的公司代码库。

实施例

namespace Company.Department.Product
{
     public class Class
     {}
}

这使得分区代码变得非常容易，并帮助程序员决定将功能放在何处。设置需要更多时间，但我觉得最终还是值得的。

Answer 8

Guidelines for Names（来自Microsoft）是一个有趣的阅读......

对于命名空间，他们说：

  

命名空间名称的一般格式如下：

     

<Company>.(<Product>|<Technology>)[.<Feature>][.<Subnamespace>]

     

例如，   Microsoft.WindowsMo​​bile.DirectX

对于课程，他们说一件事：

  

不要给类名添加前缀（例如   如字母C）。

     

接口，应该以。开头   字母I，是例外   这个规则。

值得至少扫描一下以获取一些想法......