gpt4 book ai didi

oop - 命名子类的最佳实践

转载 作者:行者123 更新时间:2023-12-04 00:59:37 25 4
gpt4 key购买 nike

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

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

我可以想到三种命名约定,并希望对如何选择提出意见。

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

因此:DoiGraphNode、DoiGraphNodeResource、DoiGraphNodeJavaResource、DoiGraphNodeWithPath 等。

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

骗子:不是很自然?一切看起来都一样?

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

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

亲:看到代码就很清楚了

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

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

因此:DoiGraphNode、ResourceNode、JavaResourceNode、GraphNodeWithPath

优点:写和读没那么多
缺点:看起来像cr*p,很不一致,可能和其他名字冲突

最佳答案

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

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

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

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

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

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

  • 我更喜欢接口(interface)和抽象基类自动出现在排序列表的首位。

    关于oop - 命名子类的最佳实践,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/574269/

    25 4 0
    Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
    广告合作:1813099741@qq.com 6ren.com