Klar kann man Checkstyle umkonfigurieren und ich schrecke auch nicht davor zurück, das zu tun - nur würde ich eben vorher gern wissen, was sich die Väter der Default-Konfiguration dabei überlegt haben.
Checkstyle meckert per default auch, wenn man abstrakte Klassen definiert. Es heisst dann, man soll besser ein Interface daraus machen - da bin ich aber gänzlich anderer Meinung. Ein Interface kann von jeder beliebigen Klasse implementiert werden, aber um von einer abstrakten Klasse abzuleiten, muss man sich da in die Klassenhierachie einfügen - das war in meinem Fall eine bewusste Einschränkung und ausserdem konnte ich bestimmte Methoden bereits in der abstrakten Klasse implementieren. Zudem halte ich mich gerne an einen einfachen Grundsatz, den ich vor langer Zeit mal gelesen hatte: die Superklasse gibt an, was eine Klasse ist und die implementierten Interfaces geben an, was eine Klasse kann.
Ebenfalls nicht einverstanden bin ich mit dem Grundsatz, dass alle Member private sein müssen. Ich habe einen Fall, in dem ich in der abstrakten Oberklasse bestimmte Methoden bereits komplett implementiere - und da drin brauche ich einen logger. Der Logger wird aber erst in den Unterklassen initialisiert (klar: von der abstrakten Klasse kann es ja keine Instanzen geben und dem Logger wird bei der Erzeugung der Name der instanzierten Klasse, in welcher er verwendet wird, mitgegeben). Da ist es viel einfacher, den logger protected zu machen, anstatt dann in den Unterklassen jedesmal mit getLogger darauf zuzugreifen...
Aber eben... ich suche ja bewusst die Diskussion für solche Fragen, um die Ideen hinter den Einschränkungen besser zu verstehen und gegebenenfalls mich oder die Checkstyle-Konfiguration anpassen zu können. Natürlich ist das nicht der Weisheit letzter Schluss, das ist mir klar.
