【问题标题】:Best practice for naming subclasses命名子类的最佳实践
【发布时间】:2010-10-09 02:59:40
【问题描述】:

我经常处于这样一种情况,即我有一个由接口或类表示的概念,然后我有一系列扩展它的子类/子接口。

例如: 一个通用的“DoiGraphNode” 代表资源的“DoiGraphNode” 代表 Java 资源的“DoiGraphNode” 具有关联路径等的“DoiGraphNode”等。

我能想到三种命名约定,希望 cmets 知道如何选择。


选项 1:始终以概念名称开头。

如:DoiGraphNode、DoiGraphNodeResource、DoiGraphNodeJavaResource、DoiGraphNodeWithPath 等

专业人士:很清楚我在处理什么,很容易看到我拥有的所有选项

Con:不是很自然吗?一切看起来都一样?


选项 2:把特殊的东西放在开头。

因此:DoiGraphNode、ResourceDoiGraphNode、JavaResourceDoiGraphNode、PathBaseDoiGraphNode、 等等等等。

亲:看代码就很清楚了

缺点:找到它可能很困难,特别是如果我不记得名字,缺乏视觉一致性


选项 3:放置特殊内容并删除一些多余的文本

因此:DoiGraphNode、ResourceNode、JavaResourceNode、GraphNodeWithPath

专业人士:写和读的东西不多 缺点:貌似cr*p,很不一致,可能和其他名字冲突

【问题讨论】:

    标签: oop naming hierarchy


    【解决方案1】:

    我通常命名类似于选项 1,尤其是当类将被多态使用时。 我的理由是最重要的信息位列在最前面。 (即子类基本上就是祖先的事实, (通常)“添加”扩展名)。 我也喜欢这个选项,因为在对类名列表进行排序时, 相关的类将一起列出。 IE。我通常将翻译单元(文件名)命名为 类名这样相关的类文件自然会被列在一起。 同样,这对增量搜索很有用。

    虽然我在编程生涯的早期倾向于使用选项 2,但我现在避免使用它,因为正如你所说,它“不一致”并且看起来不是很正交。

    当子类提供大量扩展或规范时,或者如果名称很长,我经常使用选项 3。 例如,我的文件系统名称类是从 String 派生的 但它们极大地扩展了 String 类并且有显着不同 用途/意义:

    从 String 派生的 Directory_entry_name 增加了广泛的功能。 从 Directory_entry_name 派生的 File_name 具有相当专业的功能。 从 Directory_entry_name 派生的 Directory_name 也有相当特殊的功能。

    除选项 1 外,我通常对接口类使用非限定名称。 例如我可能有一个类交互链:

    • 文本(一个界面)
    • Text_abstract(抽象(基)泛化类)
    • Text_ASCII(特定于 ASCII 编码的具体类)
    • Text_unicode(unicode 编码的具体类)

    我更喜欢接口和抽象基类自动出现在排序列表的最前面。

    【讨论】:

      【解决方案2】:

      您可以在编码标准文档中找到一些指导,例如 C# here 的 IDesign 文档。

      就个人而言,我更喜欢选项 2。这通常是 .NET Framework 命名其对象的方式。例如查看属性类。它们都以属性(TestMethodAttribute)结尾。 EventHandlers 也是如此:OnClickEventHandler 是处理 Click 事件的事件处理程序的推荐名称。

      我通常在设计自己的代码和界面时尝试遵循这一点。因此,IUnitWriter 会生成 StringUnitWriter 和 DataTableUnitWriter。这样我总是知道他们的基类是什么,而且读起来更自然。自我记录代码是所有敏捷开发人员的最终目标,所以它对我来说似乎很有效!

      【讨论】:

        【解决方案3】:

        选项三更符合逻辑继承的概念。由于您正在专门研究接口或类,因此名称应表明它不再使用基本实现(如果存在)。

        有许多工具可以查看类继承自什么,因此一个指示类的实际功能的简洁名称将比试图将过多的类型信息打包到名称中走得更远。

        【讨论】:

          【解决方案4】:

          为它们命名。

          如果命名它们很难或模棱两可,这通常表明该类做得太多(单一职责原则)。

          要避免命名冲突,请妥善选择命名空间。

          就个人而言,我会使用 3

          【讨论】:

          • 我也选择了第三个选项。在前两个中,有可能以“曲折的长名字迷宫,略有不同”结束,你很难阅读它们,甚至记住什么名字对应什么概念。
          【解决方案5】:

          使用任何你喜欢的东西,这是一个主观的东西。重要的是要明确每个类代表什么,并且名称应该使继承关系有意义。不过,我真的认为在名称中编码关系并不是那么重要。这就是文档的用途(如果你的名字适合对象,人们应该能够很好地猜测什么继承自什么)。

          对于它的价值,我通常使用选项 3,根据我查看其他人代码的经验,选项 2 可能比选项 1 更普遍。

          【讨论】:

            猜你喜欢
            • 2011-04-21
            • 2011-08-09
            • 1970-01-01
            • 2015-05-28
            • 1970-01-01
            • 2022-11-10
            • 2014-06-14
            • 2010-10-03
            • 2011-11-05
            相关资源
            最近更新 更多