Overriding classes on the fly

Question

Hello everyone!
Sorry for the vague title, as I don't know quite how to name the following example of code:
AbstractClass concreteObject = new AbstractClass( a, b ) {
            public void previouslyAbstractMethod (Object parameter) {
                doSomethingWith( parameter );
        };My question is this: if I wanted to pass a local variable into my newly overridden and substantiated class object, is it impossible to create a new constructor in my override? For example:
AbstractClass concreteObject = new AbstractClass( a, b, c ) {
            public AbstractClass( A a, B b, C c ) {
                super( a, b );
                doSomethingSpecial( c );
            public void previouslyAbstractMethod (Object parameter) {
                doSomethingWith( parameter );
        };Or do I have to live with the kind of mess I've been using as below:
AbstractClass concreteObject = new AbstractClass( a, b ) {
            public AbstractClass returnMeButAlsoDoSomething( C c ) {
                doSomethingSpecial( c );
                return this;
            public void previouslyAbstractMethod (Object parameter) {
                doSomethingWith( parameter );
        }.returnMeButAlsoDoSomething( c );It all seems a little messy to me (yeah yeah I know I should be creating separate classes for these kinds of arrangements, but when you have lots... creating single-object classes this way is so convenient!)
Appreciate the help!
Weasel.

Answer 1

My main use of this code is to pass in an extra
parameter for an event handler to use (normally the
parent object so I can run a method)... I suppose I
could start registering the parent as the event
handler, but there may be alot of event spawners to
register it with.
Implement the handler as an interface and return the appropriate type via the Factory pattern.
I'm definitely loathe to create named classes for
these objects when all I'm doing is passing a
parameter in and overriding a single and simple
method.
Not all objects are huge. In fact, some of the most useful are the smallest. I try to keep any object to a dozen methods or less, and any method to no more than screen-size in my IDE. Large classes should usually be refactored into smaller ones. I have never heard of a class that is 'too small', as long as it is doing something useful.
I'm probably alone on this point, but I like the feel
of anonymous classes taking parameters more than have
a ton of 'if then else if's in the event catcher!
If you have real objects, polymorphism will take care of this for you, and you will have cleaner, shorter code in your objects.
Thinking about it, I'm almost certain I'm alone in
this :o) In fact, I'd consider myself a bit odd!No worries. If it runs and works, it's valid. Might not be maintainable, but still would be valid.
- Saish