• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Decorator Pattern

 
Ranch Hand
Posts: 34
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Is this a fair example of a decorator pattern? The objective is to be able to wrap a callable (including another instance of this class) to string together a long chain of events. Is there another pattern better suited to this objective?



Thanks,

Andy
 
Ranch Hand
Posts: 2187
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
1. What object is being decorated?

2. What functionality is being added to the decorated object?
 
Andy Selador
Ranch Hand
Posts: 34
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Any particular object that implements Callable is being decorated. What is being added are operations performed on the result of the original Callable objects call() method.

So lets say I wanted to performe some operation on a set of data, but wanted to filter the data first. The idea is that I could say:

final double[] data = { ... };

Callable<double[]> filter = new Callable<double[]>() {

@Override
public double[] call() {
// filter data
}
};

FutureDecorator<double[], double[]> d = new FutureDecorator<double[],
double[]>(filter) {

@Override
public double[] call(double[] data) {
// perform complex operation
}
};

d.submit();
// would probably want to add some listeners to get the final result

The code I typed up in the post reply window, so there are likely some errors, and its not complete or anything, but hopefully you get the idea.
 
Jimmy Clark
Ranch Hand
Posts: 2187
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
In the code you provide, where is the original Callable objects call() method exectued?
 
Andy Selador
Ranch Hand
Posts: 34
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The Callable object passed to the constructer is ... call()ed in the decorators implemented call() method. A client would override T call(V value) to implement what they want the decorator to do. This is to make sure they don't override call() and unchain the method calls.
 
Jimmy Clark
Ranch Hand
Posts: 2187
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

The Callable object passed to the constructer is ... call()ed in the decorators implemented call() method. A client would override T call(V value) to implement what they want the decorator to do. This is to make sure they don't override call() and unchain the method calls.



This is an implementation of the Decorator design pattern, in my opinion. Personally, I would scratch the inheritance. However, I don't fully understand the purpose of this class. What you are refferring to as "a client", is another human programmer that will write Java code using these classes for an application they are creating? Is this correct?

I would not call the other programmer "a client." I would say, "A programmer would override XXX to implement what they want the Decorator to do."
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yes, this is a fair implementation of the decorator pattern.

I'm not sure what you mean by "string together a long chain of events", though.
 
Andy Selador
Ranch Hand
Posts: 34
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Well, lets say I have an array of data of type Complex. Based on certain conditions, like if a filter parameters are present, the input should be wrapped in a filter decorator, or otherwise a null decorator (just passes the data in it call()). This may be wrapped with a decorator that converts the data to a double[][] (or double[] if only the real numbers are needed). A decorator on this may then normalize the data.

So...

If you want to filter the data:



Or if you also wanted to graph it (seeing as drawline() is kind of slow and the graph may be in a scrollpane, so you'd need another thread to do it):

 
Andy Selador
Ranch Hand
Posts: 34
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The whole motivation behind this is that I don't like starting one thread that will, upon its completion, start another thread to do whatever other task is required. I guess it could call a Callable objects call(), which then calls another Callables call() on its completion, but this seemed better, because I may not always filter, or in some cases the data may already be double[] (Depending on the FFT algorithm - thats what is being used to filter). I guess I could have also included below:



In this case assuming I have an FFT callable task and an InverseFFT decorator, and the BandpassFilter only zeros out the frequency domain data to filter out.
 
Andy Selador
Ranch Hand
Posts: 34
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
How I have it set up now is using Tasks from the Swing Application Framework, where in the protected succeeded() method, the next Task is started up (or decided between). This makes it so I have to track down each link in the chain to see where the overall execution may branch or change based on certain conditions (i.e. is a filter present, is the Graph visible, etc.).

This may not be the best way to do it, and I haved considered the Template pattern, but it seemed too rigid - you do this, then this, then this, no matter what (unless it happens to be a hook). What if I didn't plan on making a particular task optional? Well, rework the template method code.
 
Who knew that furniture could be so violent? Put this tiny ad out there to see what happens:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic