java - "Design for Extension"原理与访问器(getters)/修改器(setters)意识形态之间的冲突

Question

背景:

像 CheckStyle 这样的代码分析器包含特殊的 "design for extension" rule 。它强制执行非常特殊的类设计方法。对我来说，这确实是一件有争议的事情。这是good illustration这种设计方法。关键是你要保护 super 类不被修改，只留下小“漏洞”。或者你把你的类(class)定为期末考试。对于某些安全库设计案例来说绝对有好处。

另一方面，我们有 Java 'bean' POJO style您隐藏所有数据成员并仅提供公共(public)(或 protected )访问器(getter)和修改器(setter)。在我看来，拥有现实生活中的 bean 使得它们几乎不可能被扩展。据我了解，唯一的方法是聚合 bean 并重新实现所有需要的访问器/修改器。但这严重降低了性能。

我看到声纳 dropped "design for extension" rule来自 2011 年的默认配置文件。请注意今年有人回来重新检查;-)。

问题:

因此，我计划从我的 Sonar 质量配置文件中删除“扩展设计”规则，主要是因为它使 POJO 重用变得更加困难，但我怀疑我是否错过了一些方法，该方法允许使用访问器/修改器对类进行可用继承，从而对后代保持良好的安全性。有什么标准方法可以改变我的想法吗？这个冲突可以通过“可扩展设计”的方法来解决吗？

抱歉，没有 10 年的 Java 经验，所以我真的可能会错过一些重要的东西。 ;-)

Answer 1

我会务实一点，问问你的代码的使用者是谁。如果这是供广泛(公众？)受众使用的框架，那么您可能希望仔细考虑您的扩展点。部分是为了表达您的意图，部分是为了保护不应该更改的部分。但是，如果这是在内部使用，受众较少，那么你们都可以同意稍微放松一点。