[Ktechlab-devel] Clean up after yourselves, flowpeople!! =P

P Zoltan zoltan.padrah at gmail.com
Mon Oct 12 22:21:38 UTC 2009


On Fri, 09 Oct 2009 03:03:21 +0200, Alan Grimes <agrimes at speakeasy.net>  
wrote:

> 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:
>
>
> NODE
>   -> NodeWithItem.
>
> Then, separately:
>
> AbstractWireJunction
>
> Then, inheriting from Node and abstract wire junction:
>
> JunctionNode
>
> and then inheriting from NodeWithItem and abstract wire junction:
>
> PinNode
>
> 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 +  
some action.






More information about the Ktechlab-devel mailing list