Abstract base bean class

Question

Since I haven't found anything which accurately describes my question, I thought I give it a try:

In my whole time I used abstract classes whenever I needed to distinct between different implementations of a similar schema, just like an abstract tokenizer for parsing and creating different objects from text.

However recently I found out that in bigger projects there's almost everytime a class called AbstractBaseBBE or AbstractBaseBean which almost overrides everything from the Object class. Literally all classes in those projects ultimately extend from this base class when traversing the hierarchy tree. I started to look into the definition of a bean in java and it was stated that a bean is basically just a class with getters and setters for the private fields. The AbstractBaseBBE and AbstractBaseBean classes also have methods dealing with Properties , but instead of dealing with properties I know from event handling like PropertyChangeSupport , they are just String objects.

I can't really figure out the reason why they do this or what the purpose of those abstract bean classes is.

Is there any reason other than providing additional methods for all subclasses when doing this?

The following links are examples for those:

• AbstractBaseBean.java from AOP Spring JPA
• AbstractBaseBean.java from syncope
• AbstractBaseBean.java from Entando

The PropertyDescriptor in the first is what I meant with the properties. Unfortunately some of the classes and methods used in the base classes above aren't in the project, meaning they probably got imported from an external source or lib.

I hope you can help me understand what the purpose of these classes are and when you would use something like this.

Answer 1

I think you're trying to answer the wrong question. There's no general answer to why you should always use an "AbstractBaseBean" but you can see that in each case this gives some general behavior to every object in the system. Whether that's something useful is really dependent on the system.

For example, the JPA example you cite has a set of general fields, including an id with getters and setters. The other two both provide default hashcode and equals.

Again, there's no one correct answer, but if you understand the functionality this provides you can decide for yourself if it's something you want.