【问题标题】:According to Standards Recommendations How many properties are allowed in class根据标准建议类中允许有多少属性
【发布时间】:2019-01-16 12:10:17
【问题描述】:

这里有一些代码示例

class A {
    public $attribute1;
    public $attribute2;
    public $attribute3;
    ........
    public $attributeN;
}

我需要知道我可以在课堂上拥有多少个属性。 对此PSRphpmd 或其他标准有何看法?

以芽为例,我可以有“我想要多少”,但我需要用PSRphpmd 编写它。 我正在搜索这个,但仍然找不到。

感谢您的帮助。

【问题讨论】:

  • 严格意义上没有技术限制,但是如果您生成的代码使用数十亿个属性然后实例化数百万个这样的元素,您显然会给任何系统带来麻烦。
  • 这里我想问的是:为什么你需要大量的属性(“不正常”或“如预期”或“被处理和理解的”意义上的“巨大”由人类”)。如果您正在寻找一组动态 属性,那是另外一回事,那么您应该 将它们编码为静态属性,而应编码为自定义类型的单个属性。例如,该自定义类型可以实现 ArrayAccess 接口以根据需要透明地映射事物。
  • 据我所知,PSR 中没有描述限制。甚至扩展的 PSR12 也没有描述一个类应该有多少属性。然而,类应该是小而实用的。如果你有一个拥有这么多属性的类,我猜肯定出了点问题。
  • 我认为您的问题只会吸引意见,而不是基于确凿事实的答案。例如,您自己的答案。为什么限制为 15 个字段?为什么不是16?如果我有一个包含 15 个字段的类,并且我再添加一个字段,我的性能会严重下降吗?如果我有一个包含 16 个字段的类并且我删除了一个字段,我的性能会大幅提升吗?
  • 你能提供一个示例代码,显示15个字段是好的,16个字段是坏的吗?如果其他人认为限制为 16 个字段,则该示例代码将有助于确定谁是正确的。如果你不能,你已经证明你自己的答案只是一个意见。在检查了您作为来源提供的链接之后,它似乎没有任何研究来支持自己的观点。您的来源似乎只是基于其他人的意见。

标签: php class standards phpmd


【解决方案1】:

就像 arkascha 所说,对此没有技术限制。 类是使用哈希表实现的,对其属性(或字段)的访问旨在为数百万个属性在恒定时间内高效工作。 看到这个页面:https://en.wikipedia.org/wiki/Hash_table

PHPMD 是一个分析源代码的工具。 在其Rules page 中描述的规则,包括其Code Size Rules 只是其默认配置。 换句话说,您可以将其修改为任何您想要匹配您自己的策略的内容。

例如,如果一家公司的政策规定最大字段数应为 100, 查找“TooManyFields”规则并修改如下:

<properties>
    <property name="maxfields" description="The field count reporting threshold " value="100"/>
</properties>

另一家公司可以将最大限制修改为 5 万个字段,如下所示:

<properties>
    <property name="maxfields" description="The field count reporting threshold " value="50000"/>
</properties>

你甚至可以create your own rules

总之,此处描述的规则并非所有人都可以遵循。 它们只是默认配置。 任何公司和任何开发团队都可以修改配置以匹配他们自己的策略。

【讨论】:

  • 你是对的。它们只是配置,就像任何软件的配置一样。不是官方规定。
  • @LBear 完全正确。在网站上,没有声称它们是官方规则,甚至没有建议。如果它们是官方规则,您会在 php.net 上找到它们,而不是隐藏在软件配置文档中。
【解决方案2】:

如果你打算以这种方式拥有属性,那你肯定做错了。

public $attribute1;
public $attribute2;
public $attribute3;
........
public $attributeN;

您可能需要几个数组,包含所有这些值。

【讨论】:

  • 我只是展示一个例子 $attribute2 可以是一个数组,而 $attributeN 可以是一个数组。在我的代码中,我有属性数组,但我想知道正确的情况
  • 不,当您想以专业人士的身份进行编码时,这不是好方法
  • @A.Denis - 请阅读新的Code of Conduct。关于某人的问题或代码的侮辱在这里没有立足之地。我相应地编辑了你的答案。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2021-10-02
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2014-12-31
  • 1970-01-01
相关资源
最近更新 更多