RE: Comments on the diagram (was: RE: [Pyatcron-devel-list]Cronbackend: a correction)

[NICOLOVICI Xavier]

Julien,

Some answer about the split of ScheduledTask and GenericTask


> > You're right, the relation between GenericTask and 
> ScheduledTask should be (1,1). I've used the (1,*) first 
> because I was thinking about the possibility to have many 
> tasks planed at the same time, but this sounds a bit 
> complicated to implement. Let's do it (1,1) for the moment.
> 
> The thing is that, if it's (1,1), the 2 classes should be merged IMO.
> Except if you want to make it possible to be (1,*) in the future.
> Personally, I see no advantages in sharing schedules. But 
> maybe you do ?


No, the two classes shouldn't be merged, there is a simple reason for that.
If I do the merge, then I will have a single object that will return the time 
entry and the exec command of the task. Let's imagine how the software will 
have to be designed with one Task class:

I remind you that we have to manage Cron and At deamon, which use very 
different timing structure. So, the Task class will have to deal with Cron 
entries and At system calls. 
Ok, at this points everything sounds good.
Now, have a look at specialized task. We want to make an ArchiverTask. We 
simply inherit from Task and override the "getCommand" method. But hey, this is 
wrong, a Task doesn't know about Cron an At, we must inherit from CronTask and 
AtTask.
This sounds wrong, as we will have to maintain an ArchiverCronTask and an 
ArchiverAtClass, which in OO approach is fully wrong.

Note that when working with class diagram, we are not designing databases. Even 
if you have a (1,1) relation, you have to consider also your inheritance path.

Hope that my explanation are enough clear for all of you. Do not hesitate to 
send remarks if needed.

Bye,

Xavier

This e-mail contains proprietary information some or all of which may be 
legally privileged. It is intended for the recipient only. If an addressing or 
a transmission error has misdirected this e-mail, please notify the author by 
replying to the e-mail. If you are not the intended recipient you must not use, 
disclose, distribute, copy, print, or rely on this e-mail.
We take reasonable precautions to ensure our e-mails are virus free. However, 
we cannot accept responsibility for any virus transmitted by us and recommend 
that you subject any incoming e-mail to your own virus checking procedures.