Contrary to popular belief, accessor methods do not provide any great advantage over direct field accesses, while in java they do tend to clutter the code with lots of
()s. (Compare with C#, which has an awesome feature called properties, which look like fields but behave like accessors, saving you from all the mindless
However, "no great advantage" does not mean no advantage at all. The advantages of using accessor methods instead of direct field access are as follows:
If you need to maintain binary compatibility, then you must use accessor methods, so that the class containing the fields can be modified without breaking code that has already been written to use the class. (Binary compatibility means compatibility without the necessity to modify and recompile one of the two parties. Since you are writing both the base class and its descendants, this does not apply to you.)
Accessor methods are often inevitable, while direct field access is never inevitable, so going with the "always use accessors" doctrine simplifies things and introduces homogeneity over the entire code base.
As you refactor the code trying various what-if scenarios, sometimes you discover that you have a field which needs to be replaced by a computation, which in turn means that it has to be encapsulated by an accessor method, and sometimes you discover that you have a field which stores the result of a computation and therefore does not have to be hidden behind an accessor method, so the accessor can go and the field can be made protected or public. If you keep doing this kind of refactoring a lot, then you might get to a point where you might say "aw, forget it!" and hide all fields behind accessor methods so that you don't have to keep refactoring more classes than the one you are working on.
When writing code in java and using a decent IDE, when you have an object and you want to get something from it, you tend to type
myObject.get and then the IDE shows you a list of auto-completion options, so you have everything that you can "get" from the object right in front of you. If you use fields, then you have to stop at
myObject. and browse through a list which contains everything, not only just things that can be gotten from the object. The same applies with
myObject.set when you want to set something.
In either case, I would never make a non-final field anything but private. Luckily, in your case, your
requestHandler seems to be a prime candidate for being final, (it probably only gets set in the constructor and never again,) so it is quite legitimate to make it final and protected.