pyatcron-devel-list
[Top][All Lists]
Advanced

[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>




reply via email to

[Prev in Thread] Current Thread [Next in Thread]