[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Comments on the diagram (was: RE: [Pyatcron-devel-list]Cronbackend:
RE: Comments on the diagram (was: RE: [Pyatcron-devel-list]Cronbackend: a correction)
Tue, 18 Nov 2003 10:58:36 +0100
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
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.
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.
- RE: Comments on the diagram (was: RE: [Pyatcron-devel-list]Cronbackend: a correction),
NICOLOVICI Xavier <=