背景：
像CheckStyle这样的代码分析器包含特殊的"扩展设计"规则。它强制执行真正特殊的类设计方法。就我而言，这确实是一件有争议的事情。这里很好地说明了这种设计方法。关键是要保护超级类不受只留下小"洞"的修改。或者你把你的课定为期末考试。对于安全库设计的某些情况来说绝对是好的。
另一方面，我们有Java"bean"POJO风格，您可以隐藏所有数据成员，只提供公共(或受保护(访问器(getter(和赋值器(setter(。在我看来，有了现实生活中的豆子，它们几乎不可能被扩展。据我所知，唯一的方法是聚合bean并重新实现所有需要的访问器/赋值器。但这严重降低了性能。
我看到SONAR在2011年从默认配置文件中删除了"扩展设计"规则。请注意今年有一个人回来复查；-(。
问题：
因此，我计划从我的Sonar质量配置文件中删除"扩展设计"规则，主要是因为它使POJO的重新使用变得更加困难，但我有一些怀疑，如果我错过了允许类的可用继承的方法，访问器/变异器可以保持对后代的良好安全性。有什么标准的方法可以改变我的想法吗？这种冲突是否可以通过采用"为扩展而设计"的方法来解决？
对不起，在Java没有10年的时间，所以我真的会错过一些重大的东西
我会很务实，问问谁是代码的消费者。如果这是一个供广大(公众？(受众使用的框架，那么您可能希望仔细考虑您的扩展点。部分是为了表达你的意图，部分是为了保护那些不应该改变的部分。然而，如果这是针对较小受众的内部使用，那么你们都可以同意放松一点。