背景：
诸如CheckStyle之类的代码分析器包含特殊的“扩展设计”规则。它实施了真正特殊的类设计方法。就我而言，这确实是有争议的事情。这很好地说明了这种设计方法。关键是您可以保护超类不被修改，只留下很小的“漏洞”。或者您将自己的课程定为期末考试。对于安全库设计的某些情况绝对有利。
另一方面，我们具有Java'bean'POJO样式，您可以在其中隐藏所有数据成员，并仅提供公共（或受保护）访问器（获取器）和更改器（设置器）。根据我的观点，拥有现实生活中的豆子使得它们几乎不可能被扩展。据我了解，唯一的方法是聚合bean并重新实现所有需要的访问器/更改器。但这严重降低了性能。
我看到SONAR在2011年从默认配置文件中删除了“扩展设计”规则。请注意，今年有一个人返回以重新检查它;-)。
问题：
因此，我计划从Sonar质量配置文件中删除“扩展设计”规则，主要是因为它使POJO的重用变得更加困难，但是我怀疑是否错过了一些方法，该方法允许在访问者/变异者保持良好安全性的情况下继承类。反对后代。有什么标准的方法可以改变我的想法吗？可以采用“扩展设计”方法来解决此冲突吗？
抱歉，在Java领域没有10年，所以我真的很想念很多东西。;-)
我会务实的，问一下您的代码的使用者是谁。如果这是供广大（公众？）受众使用的某种框架，那么您不妨仔细考虑您的扩展点。一方面，表达您的意图，另一方面，保护不应更改的部分。但是，如果这是供较小的受众内部使用的，则您都可以同意放松一些。
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句