[kplato] Some code for KPTProject::getDuration()
Thomas Zander
kplato@kde.org
Mon, 27 Aug 2001 23:20:12 +0200
--yrj/dFKFPuw6o+aM
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Mon, Aug 27, 2001 at 09:24:44PM +0100, John D Lamb wrote:
> Thomas Zander wrote:
>=20
> >=20
> > The 3 lists are as follows;
> > - m_nodes contains all child nodes in the logical structure.
> > (making table contains child node polishing wood)
> > - m_dependChildNodes contains all nodes that are dependent on this node
> > to [finish|start] before they [start|end]
> > - m_dependParentNodes contains all nodes that this nodes depends on to
> > [finish|start] before I can [start|end]
> >=20
> I think we can assume that=20
> - m_dependChildNodes contains all nodes that are dependent on this node
> to finish before they start
> anything more complicated can be represented by dummy nodes of some
> kind. For example If activity B can't start until A has started, create
> a node A_start that must precede both A and B and has duration 0. In
> practice, node like A_start are probably very rare. I haven't seen them
> in the OR literature anywhere.
>=20
> If we don't assume this, the PERT/CPM stuff is going to get slow and
> complicated.
ok, I don't know enough about that, I'll take your word for it.
> > Whoa!!! That is a private list, only for internal use, don't use it lik=
e that
> > that is not OO.
> > In this I mean that it is not nice to assume things about the internals=
of
> > data you are pointing to, even if you are based on the same class.
> > In other words; either store your own data, or use a method on the remo=
te
> > object for searching.
> >=20
> Yes? My point was that the m_dependChildNodes and m_dependParentNodes
> violate OOP just as much as my suggestion because if node A has a
> dependChildNode (actually a KPTRelation) R it must have parent A its
> child B must have R as a dependChildNode.=20
I don't see how this violates OO.
It is all based on objects who know each other (have pointers to..), nothin=
g=20
more.
OO is about black-box objects and an API for talking to those objects, wher=
e=20
any object can know another by reference and by API (interface). But never
knows its internals.
This is the basis of OO...
/me confused...
> Actually, I prefer m_dependChildNodes and m_dependParentNodes.
Problem solved ;)
> Here is how I would deal with adding a KPTRelation to a project. I'm not
> sure a static function is sensible. I'm not even sure the function is in
> the right class. But note how we can use the data structure to test the
> precondition that cannot be encapsulated in the OO structure. (You may
> have to guess what some of the helper functions do.) The STL guarantees
> efficiency and that the iterators will always make sense. It also mixes
> easily with the Qt stuff and can be hidden in KPTRelation.cc or
> KPTNode.cc or ...
The checking-logic is good, but i don't think it belongs in the data model.
The checking for the consitency of the data model should be on a heigher le=
vel,
just below the GUI code.
What I would do is put the code in a (new) class that is created specially =
for
creating new data structures.
I'll set up an stucture for that if you like.
If we leave out the code to do the checking below, the method comes down to:
void KPTNode::addDependChildNode( KPTNode *node, TimingType t, TimingRelati=
on p, KPTDuration lag) {
KPTRelation *relation =3D new KPTRelation(this, node, t, p, lag);
m_dependChildNodes.append(relation);
node->addDependParentNode(relation);
}
Which is allready in CVS (just added a bugfix since it lacked the last line=
).
--=20
Thomas Zander zander@earthling.n=
et
The only thing worse than failure is the fear of trying something new
--yrj/dFKFPuw6o+aM
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE7irmMCojCW6H2z/QRAmyyAKDT7/hLSxBX/1pwHJHfQltSRvUAIQCgkAEl
FX7NBXiQkaT3lqcgGBUYwOU=
=Rar1
-----END PGP SIGNATURE-----
--yrj/dFKFPuw6o+aM--