• 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

Question on object instantiation that requires state

 
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello all,
I'm designing a "task chain" system and need to instantiate a "task chain" & "tasks" that form the chain and then run them (no - i'm not using any BPEL/ BPM techniques).

I think the "chain" and its constituents ("tasks") fit into Spring's object creation functionality - configurable, IOC, lists etc.. are all built in.

The problem I'm seeing now is that creation of some of these "tasks" objects requires "state" information. The state is available with the code portion creating (and using) the "chain". Every "task" (lets say) will also be passed the "state" when it is invoked.

What would be a good way to do this? I have a few thoughts, but would want to review them with the folks here :
1.> Instantiate and invoke a wrapper "task" that delegates the actual processing to a correct "task" object depending on the "state" passed to it.

2.> Lazy load the stateful-task using custom factories. Ensure that the factory gets the "state" in a ThreadLocal (or something)

Does that sound ok? Anything better? Please comment and let me know.

--
Madhur Tanwani
 
ranger
Posts: 17347
11
Mac IntelliJ IDE Spring
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Off the top of my head, because I didn't put much thought into this.

But what about the Command pattern.

Also, is this a Spring question? If it is, then I will take tasks as being Services, and Services, Controllers, EndPoints, Repositories should never ever hold state that can change by user. State that doesn't change once it is instantiated is ok.

Mark
 
Ranch Hand
Posts: 1936
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Could you please to give some example code of what you're trying to do?
 
Madhur Tanwani
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Kengkaj Sathianpantarit wrote:Could you please to give some example code of what you're trying to do?


Sure. Glad you asked.

I'm implementing this TaskChain as a chain of responsibility pattern :
T1 -> T2 -> T3 -> ... -> Tn
Each task does a specific processing on its inputs (say BillingInfo).

I'm outsourcing all the configuration of the task (Tn) objects, chain list piping and configuration to Spring. Thus, a task would be a bean configured via spring to form the chain.

Now, lets say there is a task that needs to performed on the basis of some state that the executor of this chain will initialize. Lets say this state information is "account type". Depending on the account type the tasks process inputs differently. Hence, there could be a task which needs to do this :
1.> if the account type is X, validate BillingInfo to not have Y
2.> if the account type is A, validate BillingInfo to have B & C

Now one solution is to implement a single task, and do the above if-then-else in it. I dont quite like this.
Other solution is to implement 2 separate tasks that just do the above and instantiate the correct one (and pipe it in the chain) depending the state (account type). That's what this question is about.

Thanks for reading & helping!
BTW the use cases above are not what I'm actually going to do - its just to convey my intention
 
Madhur Tanwani
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Mark Spritzler wrote:Off the top of my head, because I didn't put much thought into this.

But what about the Command pattern.

Also, is this a Spring question? If it is, then I will take tasks as being Services, and Services, Controllers, EndPoints, Repositories should never ever hold state that can change by user. State that doesn't change once it is instantiated is ok.

Mark


That's correct, its not an ever changing state. The executor initializes the state and the tasks use it.

Command Pattern : Yes that's exactly what I was referring to with the "wrapper" class in option 1 - sorry my description was not very explicit.
 
Hong Anderson
Ranch Hand
Posts: 1936
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'm not sure do you mean you want Spring to instantiate task objects? If so why?
I think the application code should instantiate task objects. You can use Factory Method pattern.
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic