[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Comments on the diagram (was: RE: [Pyatcron-devel-list]Cronbackend:
From: |
Julien Olivier |
Subject: |
RE: Comments on the diagram (was: RE: [Pyatcron-devel-list]Cronbackend: a correction) |
Date: |
Tue, 18 Nov 2003 11:42:49 +0000 |
> 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.
>
Just to be sure, what you are saying is that, if we merge those 2
classes, each task type class would have to be whether a CronTask or
AtTask (by inheritance) explicitly, which would be bad. Is that it ? If
that's it, I agree with you.
--
Julien Olivier <address@hidden>