Below I describe what I'm trying to do and how I think I will do it. What I'm hoping is that a design pattern exists for using one object to configure another. This would allow me to have a nice generic
Job class rather than an ever-increasing list of
If there is such a design pattern, what's it called and how would I apply it to my use case? I'm using the Symfony framework and working in PHP.
Part of my application is a
Task list for user activities. UserA creates
Task $task1 and it shows up in the
Task list. UserB accepts
$task1 which changes the task's state to "accepted";
$task1 which changes the task's state to "started"; etc. I've implemented the preceding as a state machine and it works well.
Task carries a
Payload has 2 properties:
Payload$sopis an SOP object that contains configuration information.
Payload$inputvarsis an array of input vars provided by the
and a method:
makeJob(SOP $sop = null, $inputvars = null), a factory method that creates a
Jobobject configured according to the
SOPobject. This is the "and magic happens" spot in my code.
$task1->status changes to "started",
$task1->payload->makeJob() is called and a new
Job $job is created. UserB will interact with a form to input fields required by the
SOP that produced
$job. When UserB changes
$job->status to "completed", the state of the
$task1 will also be changed to "completed".
So, is this a reasonable way to reduce subclassing of
Job? Is there a more efficient way, given the large number of possible
Job subclasses (we're talking hundreds here).