• Post Reply Bookmark Topic Watch Topic
  • New Topic

Anonymous Vs. Inner Vs. Independent Class for Event Listeners

 
Saket Barve
Ranch Hand
Posts: 229
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello,

This is a question regarding appropriate coding approach.

For listeners, we have the following approach:
- Anonymous Class Vs. Inner Class
- Inner Class Vs. Independent, Stand-alone Class

My understanding is that for listeners performing minimal functionality, an anonymous class will do just fine. For all the rest, I prefer to use inner classes.

During the code review, suggestion was that I create independent class for one of my inner class since the main class has gotten to be about 1200+ lines, all inclusive.

I'd really appreciate a feedback.

Thanks,
Saket
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
1200+ lines *are* a lot, so I certainly would want to extract some other classes.

I couldn't tell whether extracting the listener class would be a good idea without seeing the actual code.
[ August 22, 2006: Message edited by: Ilja Preuss ]
 
Ken Blair
Ranch Hand
Posts: 1078
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yeah, but GUI components tend to get pretty bloated. In my experience it's not uncommon for a component to have a lot of necessary code attached to it that must rely on implementation details of that component. Why expose any of the listeners and other trash needed to deal with low-level events by making another top-level class?

Still, 1200 lines is almost certainly too much. Instead of pulling out arbitrary things like listeners and moving them to a new class in the name of less lines you ought to analyze the design. There's probably several things your component does that could be moved elsewhere. For example, could some of the painting be delegated to another object without coupling the two?
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Ken Blair:
Yeah, but GUI components tend to get pretty bloated.


In my experience, that's a matter of choice, not a law of nature.

In my experience it's not uncommon for a component to have a lot of necessary code attached to it that must rely on implementation details of that component.


Yes, it's not uncommon. In my experience, that doesn't mean that it's good, or necessary. Typically a complex component can easily be composed of less complex components, if you care to invest the time to come up with a finer grained design.


Why expose any of the listeners and other trash needed to deal with low-level events by making another top-level class?


I'm not sure I understand this question.

I'm certainly not advocating to simply make a listener that is heavily coupled to a component a top level class. It might be possible - and sometimes even desirable - though, to decouple it from the component so that it actually makes sense to make it a top level class.

But most often that's not what I'm doing. Most often my listeners are dead simple one-liners.

Instead of pulling out arbitrary things like listeners and moving them to a new class in the name of less lines you ought to analyze the design.


Yes, full agreement here.
 
Ken Blair
Ranch Hand
Posts: 1078
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes, it's not uncommon. In my experience, that doesn't mean that it's good, or necessary.


I didn't intend to suggest otherwise.

Typically a complex component can easily be composed of less complex components, if you care to invest the time to come up with a finer grained design.


That's what I'm getting at, wait for it...

I'm not sure I understand this question.


The OP geared their question towards pulling out listeners rather than refactoring the design.

But most often that's not what I'm doing. Most often my listeners are dead simple one-liners.


Which is what I'm addressing. Rarely are listeners something that can easily be pulled out into a top-level class that makes sense. Hence why the OP being focused on pulling those out into other classes might be a mistake...

Yes, full agreement here.


Well there you go, that was the point. (I told you to wait for it)

In other words, their component is doing too much and should probably be broken into smaller components. I had a GUI component that displayed a form which got to be rather large. It's quite small now, mostly due to the fact that things like the address were pulled down into their own components with an "AddressModel" backed by our "Address" interface, a view defined by our "AddressUI" interface and a "DefaultAddressUI" to provide the simple, most common GUI implementation in the form of a JPanel.

Suddenly a bunch of code that did things like update and retrieve three different addresses went from a hundred lines to two. Saved a heck of a lot of time on the next three forms which just plugged in an address in seconds without having to reinvent the implementation, model, etc. It's all thread-safe too and plays nice with the EDT.
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Somehow I'd assume that the reviewers *might* have analyzed the design before coming up with the recommendation. That's why I said I had to see the code to say whether I agree.

I, perhaps wrongly, understood you to say that it's never a good idea to make a listener a top level class. That's not my experience - there *are* situations where it actually can make sense, design-wise.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!