接口的描述性命名约定&抽象类

时间:2012-01-23 13:12:40

标签: c# architecture naming-conventions

我最近一直在尝试以更具描述性的方式命名抽象类和接口。主要是试图确保他们不偏离预期的目的。

因此,对于抽象类,我一直使用 IsA IsAn 用于接口 ICan IPerform

例如,而不是IOperationManager; ICanPerformOperationManagement

我在课堂上发现这看起来更好。

我确定我不是第一个这样想的人,并且想知道是否有人对接口和抽象类使用了任何类型的描述性命名约定?它会扩展到大型项目,还是只会增加混乱?

编辑:这个问题太主观了吗?

2 个答案:

答案 0 :(得分:2)

Abtract类我倾向于将Base附加到它,例如ViewModelBaseNodeBase

对于接口,我倾向于描述对象,因此IOperationManager而不是ICanPerformOperationManagement。话虽如此,我偶尔会将一个界面从相当无聊的IDrawable重命名为更有趣的ICanBeDrawn

考虑开发人员如何使用代码库。如果你正在考虑intellisense,并且知道你有一个名为OperationManager的类,你会期望它的接口是IOperationManager。很少有人会在第一次尝试时猜测他们应该开始输入I..C..a..n..P..e..等等......

答案 1 :(得分:2)

对我来说,这是关于简短和描述性的,消除名称中的冗余术语。

个人认为不需要在接口名称中包含CanPerform,因为首先使用接口描述了 - 然后属性和方法描述它应该能做什么。以这种方式考虑一下 - 对于实现接口的类型,你会有ICantPerform...吗?当然不是;界面要么已经实现,要么就不存在了。

如果开发人员了解界面是什么,那么他们就会理解这一点。如果他们不这样做;他们不应该使用接口。

抽象类型也是如此。 IsAIsAn也是多余的,因为只要类型继承了它,关系就完成了。正如Dr.Andrew所说(+1那里) - Base后缀很有用,因为它意味着有实现的抽象行为(这也很适合BCL的其余部分)。

对我来说,IOperationManager是有道理的; ICanPerformOperationManagement很笨拙。