To me, the code is worse than before. Less clear, less self-contained. And just for saving a few lines of code which are very simple. Just my 2 cents.

Thanks @simonharrer for your feedback. Besides "saving a few lines of code" I had the following motivation in mind:

• Invoke these FieldChecker as validators in the entry editor (i.e. show errors directly while editing an entry)
• Move from strings to valued types. Most of the checkers work with strings, instead of using data objects (for example, they use regular expressions to match pages instead of parsing the string to a Page object and let this class check if it's a normalized page string; the ISSN checker is an exception and in a style I prefer). My hope was that all this parsing can also be moved to the parent FieldChecker class, so that each checker only operates on a parsed object (like ISSN).

But probably all these things can also be accomplished without the FieldChecker as abstraction layer. @JabRef/developers if you think that it over-complicates things, just close this PR.

Ok, I see. Thanks for clarification. The PR makes more sense to me now. :-)

In that case, I would vote for a FieldChecker interface that is implemented by each of these classes you refactored. Then, another class can bridge between a Checker and a FieldChecker like an adapter. The FieldCheckers can then be easily used within the entry editor.

Working with generics could be the way to go for your second point, but I am unsure how this will look. The idea behind this change could be to use the decorator pattern. On the outside, there is a String FieldChecker, and on the inside an ISSN FieldChecker, for instance.

Thanks @simonharrer for this suggestion! I now implemented the FieldCheckers via the adapter pattern and think it is more clear than it was before.
Hopefully you finish your thesis quickly so that you have more time for JabRef again 😄