Your proposed changes add the mousewheel and key listeners to more than just the component that contains the zoomable text. I think that's not desired.

Regarding the design choice of replacing the constructor Base argument by adding the listeners outside of the class:
I would say that having this zoomable text is part of one of the monitor classes and not something that should be added in the class where the monitor is created instead (when some random developer attempts to find this code, they would likely inspect the monitor classes and find out that the code is not there). I however also agree that monitor classes should not have to depend on the Base class. A solution that came up in my mind is:

• Create some TextZoomComponentSupport (example name) interface that contains the addEditorFontResizeListeners(Component), addEditorFontResizeMouseWheelListener(Component) and addEditorFontResizeKeyListener(Component) methods.
• Pass this new interface as an argument to the text monitor classes constructor.
• Make the Base class implement this interface.

This allows for the Base class to be passed, but the text monitors not to depend on it (but rather on a more simple interface), without requireing classes that use the text monitors to call additional methods.
As for fixing the unit test, passing a null TextZoomComponentSupport could be checked for, but I'd still encourage adding Mockito to be able to test things such as whether the passed interface's methods are actually invoked.

What are your thoughts on this @cmaglie?

@cmaglie Regarding usage of this:
This is something I got used to (Oh no, I punned). I use it for several reasons:

• Readibility: Seeing this.var immediately allows someone to tell that var is a field and not a local variable (especially useful on for example Github, where fields do not have a different color than local variables).
• Prevent accidental coding mistakes: Imagine returning the str field in a long method, and adding a str variable on top of that method because the name was convenient. This would result in valid code where the reference to the str field has unintendedly turned into a reference to the new str variable.
• Allow constructors (but also methods) to be passed arguments with the same name as a field. Example: public MyObj(Base ibase) {base = ibase;} VS public MyObj(Base base) {this.base = base;}. I generally like this because smart IDE's show constructor/method argument names during autocompletion, and having ibase there just looks a bit less clean. Javadocs also contain these argument names.

The only downside of adding this that I can think of is that it costs more characters and therefore can force you to linewrap earlier.
Note that in inner classes, MyObj.this.myVar can be used to refer to the outer class field, since this within the inner class would refer to that class instead.

I would like to hear your thoughts on this as well, since not using this in this project must have been a choice at some point.

Hi @Pieter12345, sorry for the long delay

Your proposed changes add the mousewheel and key listeners to more than just the component that contains the zoomable text. I think that's not desired.

why not? in the end it's an AbstractTextMoniror! intuitively I expect this to work exactly this way (unless there is a more robust way to add a listener to all child components?)

I would say that having this zoomable text is part of one of the monitor classes and not something that should be added in the class where the monitor is created instead

IMHO the "mousewheel-zoom" behaviour should not be part of AbstractTextMonitor, to me seems that this is more like a "shortcut" (exactly as the "CTRL +" or "CTRL -") that is added from the caller side, exactly as we do with the other shortcuts.

• Create some TextZoomComponentSupport (example name) interface that contains the addEditorFontResizeListeners(Component), addEditorFontResizeMouseWheelListener(Component) and addEditorFontResizeKeyListener(Component) methods.
• Pass this new interface as an argument to the text monitor classes constructor.
• Make the Base class implement this interface.

For solving this particular issue (removing dep from Base) IMHO it's not worth it. It may be worth it if we could make it handle all the aspects of text zooming in particular also in the applyPreferences we may add methods to theTextZoomComponentSupport to retrieve fonts that are currently get from Theme and PreferencesData:

  @Override
  public void applyPreferences() {

    // Apply font.
    Font consoleFont = Theme.getFont("console.font");
    Font editorFont = PreferencesData.getFont("editor.font");
    textArea.setFont(Theme.scale(new Font(
        consoleFont.getName(), consoleFont.getStyle(), editorFont.getSize())));

but, again, it's worth it? in my opinion at this point in time probably not, if we see that this starts to get ubiquitous we may think a refactor like you suggested.