Skip to main content
Software Engineering

Return to Question

Tweeted twitter.com/StackProgrammer/status/676285338004955136
clarified that decorator contained more than one method
Source Link
sqykly
sqykly
  • 219
  • 1
  • 7

I was refactoring some java to use decorators. All of the decorators inherited from a class ThingDecorator, let's say. This consisted entirely of:

SomeType methodName(OtherType otherThing) {
    return decoratedObject.methodName(otherThing);
}

ThisFor maybe 20 methods of that form. This is like writing "this thing is a decorator" over and over again, which just drives me nuts as a DRY enthusiast. Every addition to the activities of this class needs an addition to the class[es] that form the basic un-decorated behavior and the decorator, but it's always just "this thing is still a decorator!" all over again. Is there any way to express once that an object is to delegate all non-overridden methods to some member field?

I was refactoring some java to use decorators. All of the decorators inherited from a class ThingDecorator, let's say. This consisted entirely of:

SomeType methodName(OtherType otherThing) {
    return decoratedObject.methodName(otherThing);
}

This is like writing "this thing is a decorator" over and over again, which just drives me nuts as a DRY enthusiast. Every addition to the activities of this class needs an addition to the class[es] that form the basic un-decorated behavior and the decorator, but it's always just "this thing is still a decorator!" all over again. Is there any way to express once that an object is to delegate all non-overridden methods to some member field?

I was refactoring some java to use decorators. All of the decorators inherited from a class ThingDecorator, let's say. This consisted entirely of:

SomeType methodName(OtherType otherThing) {
    return decoratedObject.methodName(otherThing);
}

For maybe 20 methods of that form. This is like writing "this thing is a decorator" over and over again, which just drives me nuts as a DRY enthusiast. Every addition to the activities of this class needs an addition to the class[es] that form the basic un-decorated behavior and the decorator, but it's always just "this thing is still a decorator!" all over again. Is there any way to express once that an object is to delegate all non-overridden methods to some member field?

Source Link
sqykly
sqykly
  • 219
  • 1
  • 7

How to DRY decorator pattern and other delegation in java

I was refactoring some java to use decorators. All of the decorators inherited from a class ThingDecorator, let's say. This consisted entirely of:

SomeType methodName(OtherType otherThing) {
    return decoratedObject.methodName(otherThing);
}

This is like writing "this thing is a decorator" over and over again, which just drives me nuts as a DRY enthusiast. Every addition to the activities of this class needs an addition to the class[es] that form the basic un-decorated behavior and the decorator, but it's always just "this thing is still a decorator!" all over again. Is there any way to express once that an object is to delegate all non-overridden methods to some member field?