On Fri, 09 Oct 2009 03:03:21 +0200, Alan Grimes <agrimes@...>
> I wish the flowpeople (I'm not one), would clean up after themselves...
> Right now I'm trying to move fpnode into flowparts to make things a bit
> more orderly. (use "svn mv" to move files around.)
> With great respect to the previous refactoring done on my behalf of the
> Node heirarchy, there are still many problems that need to be examined
> and refactored. There is a great deal of code in ecnode that should be
> in Node or, maybe, connector.
> Kdevolp's show class heirarchy shows what's going on now...
> For testing purposes, it would be awesome to be able to instantiate
> abstract itemDocuments and ICNdocuments.
It can be done it you inherit a new class from them and define the
abstract methods in that class.
> Basically, the problem is we have two types of nodes, nodes attached to
> CNItems and nodes that are floating on connectors. So the heirarchy
> should be something vaguely like:
> -> NodeWithItem.
> Then, separately:
> Then, inheriting from Node and abstract wire junction:
> and then inheriting from NodeWithItem and abstract wire junction:
> I think this will further improve the ratio of variables that exist in a
> given object to those that are actually required to make that object
> work, and allow code all over the place to be leaner and less buggy.
I don't see why would be this simpler than the current situation. There
might be some code duplication, but my point is that the more obvious a
code is, the easier it's to maintain.
"Code all over the place" sounds more like bad design, which should be
changed. The role of the each class/object should be clearly defined.
> Also, I'm coming across lots and lots of "fail silently" code that I'm
> taking out to help us further reduce the number of glitches...
Those should be hunted down and replace with error / warning message +