1

BACKGROUND:

Code analyzers like CheckStyle contain special "design for extension" rule. It enforces really special class design approach. As form me it is really controversial thing. Here was good illustration of this design approach. The key is you protect super class from modification leaving only small 'holes'. or you make your classes final. Definitely good for some cases of secure library design.

From the other hand we have Java 'bean' POJO style where you hide all your data members and provide only public (or protected) accessors (getters) and mutators (setters). Having real life beans this makes them almost impossible to be extended as by my opinion. As far as I understand the only way is to aggregate bean and re-implement all needed accessors / mutators. But this seriously lowers things ilke performance.

I see SONAR dropped "design for extension" rule from default profiles in 2011. Please pay attention one person have returned this year to recheck it ;-).

QUESTION:

So I plan to drop "design for extension" rule from my Sonar quality profile primarily because it makes POJO re-usage much harder but I have some doubt if I missed some approach that allows usable inheritance of the classes with accessors / mutators keeping good security against descendants. Is there any standard approach that could change my mind? Can this conflict be resolved with "design for extension" approach adopted?

Sorry, no 10 years in Java so I could really miss something massive. ;-)

Community
  • 1
  • 1
Roman Nikitchenko
  • 12,800
  • 7
  • 74
  • 110
  • 2
    I would be pragmatic, and ask who the consumers of your code are. If this is some framework for use in by a wide (public?) audience then you may wish to consider carefully your extension points. Partly, to express your intent, partly to protect the parts that shouldn't change. However, if this is for use internally with a smaller audience, then you could all agree to be a bit more relaxed. – Romski Aug 06 '14 at 00:05
  • And this is the key, it is internal component for relatively small company... but this is Big Data infrastructure core component so it is widely used by most of projects in some way. This causes my doubts. However I came to conclusion I can ignore extension security as all users are known. So I decided just not to follow this 'design for extension' approach. But it is always good to re-think your approaches. ;-) – Roman Nikitchenko Aug 06 '14 at 04:16
  • Don't know if this convention has a name: But what about enforcing to call the `super`-method in every method you override? This ensures proper extensions from the extending class, instead of enforcing it in the base class. – Waog Aug 06 '14 at 14:34
  • @Romski's comment should be the answer imho. I would not generally require classes to be "designed for extension" in the spirit of the check. But if you have a class that you know will get extended a lot, you can use the check to make sure you remain in control of the extension points. – barfuin Aug 06 '14 at 20:26

1 Answers1

1

I would be pragmatic, and ask who the consumers of your code are. If this is some framework for use in by a wide (public?) audience then you may wish to consider carefully your extension points. Partly, to express your intent, partly to protect the parts that shouldn't change. However, if this is for use internally with a smaller audience, then you could all agree to be a bit more relaxed.

Romski
  • 1,912
  • 1
  • 12
  • 27