"One-time use methods" - looks better, but harder to read?

Question

I've got a constructor that has a LOT of setup to do, for a pretty complex object.

Lots of this setup includes adding listeners to other objects within this one, so my constructor is full of the boilerplate anonymous inner class method descriptions. And since you NEED to implement them all, even if you don't want to use them, they end up taking up tons of space. Example:

     myTag.addMouseListener(new MouseListener()
     {

        public void mouseUp(MouseEvent e)
        {
          // do nothing
        }

        public void mouseDown(MouseEvent e)
        {
           myTag.setListVisible(true);
        }

        public void mouseDoubleClick(MouseEvent e)
        {
           // do nothing
        }
     });

It's just a whole bunch of nothing (and yeah, I know the formatting is ugly, too, but that's our team's style, no point arguing).

I put a bandaid on this ugliness by creating methods just for these one-time operations, such as

addEventListeners()

and stuff like that. But I feel like these go against what a method should be: modular and reusable code that's as generic you can make it. Instead, I've got these specific one-time methods that only exist because I don't want to make their bodies inline.

How do you go about handling this type of situation? I know all the boilerplate stuff is a necessary evil in this case, but do I put it all in my constructor, which is the only place it's ever needed, or do I break it out into methods, which are only ever used once and only exist to hide ugly paragraphs of code?

EDIT: to be clear, my example was merely a symptom of lot so of boilerplate code. I am definitely using adapters now (thanks for the suggestions!) But my question is ultimately about whether it makes sense to break out some code from a long, busy constructor into bits and pieces, even if they're only used once and serve no modular purpose other than to move code out of the big constructor to make it more readable.

Answer 1

To avoid this type of problems Swing introduced Adapters, which are empty implementation of listeners. So instead of

 myTag.addMouseListener(new MouseListener()
 {

    public void mouseUp(MouseEvent e)
    {
      // do nothing
    }

    public void mouseDown(MouseEvent e)
    {
       myTag.setListVisible(true);
    }

    public void mouseDoubleClick(MouseEvent e)
    {
       // do nothing
    }
 });

you can simply use

 myTag.addMouseListener(new MouseAdapter()
 {

    //override only method you need
    public void mouseDown(MouseEvent e)
    {
       myTag.setListVisible(true);
    }

 });

BTW Adapter can implement many similar interfaces like in case MouseAdapter it is empty implementation of MouseListener, MouseWheelListener, and MouseMotionListener

---

If you are wondering if it is better to have one long method vs few short ones, even if they will be used only in one place I would go with few short onces, just for the reason that it would be easier to read your code with properly named methods. Also (very important point for many people) smaller methods are easier to test.

Answer 2

You can try to think of these things more like services. Use the service you need only. en.wikipedia.org/wiki/Service_layers_pattern

There is more than one design patter you can use here to make this more usable.

The Observer Design Pattern is a good start.

Also here is a good way to approach it as well in this question: Design pattern for mouse interaction