[kplato] Application Class Structure

[John D Lamb]

Thomas Zander wrote:
 
> I am mainly a Java programmer, sorry for the default question; why are
> methods which are implemented in parent classes not displayed in the child
> classes?
> Makes it hard to figure out functionaility.
>
I think this is a feature of doxygen. There is a "List of all members",
that should help. I think it's six and half-a-dozen whether this is
easier than javadoc. It's harder in javadoc to identify which class
implements a member function.
> 
> Could you ellaborate on what are predecessors and successors?
> It looked to me like these are just interface methods to the
> hierarchy of projects/tasks/subtasks. So I am wondring why there
> are so many functions for this, a
>     QList<Node*> getParents();
>     QList<Node*> getChildren();
> would suffice.
These are not related to the tree structure at all, but to the directed
graph of
dependencies among the tasks. getParent and getChildren are probably
better names for the
tree structure.
> In Node you have getPredecessors() and getAllPredecessors()
> I would not have a getAllPredecessors() method, this breaks the OO
> aprouch. (recursive methods are OK, but not in the data-structure)
> same for getAllSuccessors()
I think you're probably right. 
> I don't see a reason why a project is different from a subproject, they
> both have the same functionality.
> The only difference is if they have parents or not. But this is not
> defined in the class itself, just in the usage of it.
The start and end node of the project shouldn't be visible to the user,
but apart from that I can't see the difference. They might easily end up
being the same class.
> I honestly admin that the risk/duration discussion was over my head, but
> the implementation of the tree of classes seems a bit to much for me.
> I think one class should suffice, maybe have multiple constructors..
> The main reason to use one class is becuase the basic duration is a data
> object, all the classes you have under them are calculations on that object.
> I suggest to move those to the duration class (make it know things about
> itself).
> Maybe add a number of static methods which return a duration object..
I'm not yet convinced of this, but its good to think about it. 

JDL