[Ktechlab-devel] A few more ideas

[P Zoltan]

On Tue, 08 Jul 2008 21:55:58 +0200, Alan Grimes <agrimes at speakeasy.net>  
wrote:

>> Any other TODOs?
>
> just general code-cop operations...
>

  I would also like to see:
- more documentation comments in the code
- automated tests: there could be a program, which loads a circuit in the  
simulator, runs the simulation and compares the results with the correct  
ones. If there is a significant error ( +/- 5% ?), then something is wrong.
- some kind of logging, for debugging purposes

> When you look at Node class, you see a field which basically sez what
> kind of node it is... This is a C style of code, there are four or five
> possible types, this implies that there is code elsewhere that is
> contingent on what type it is.
  I've seen the same in the Element, Variable, CanvasManipulator and  
DrawPart classes too -- those should be fixed too, but let's handle one  
problem at a time.

  I've uploaded a class diagram for the Node hierarchy here:
  http://ktechlab.org/wiki/index.php?title=Image:Node_tree.gif

  I think the first thing to do is to define clearly each class' role.  
Knowing which class does what, and what it does not, we can define the  
interfaces for them.

  From the documentation comments:

Node -  A standard node that can be associated with a Connector or a CNItem
CNItem - Essentially, all items that live on ICNDocument should inherit  
 from this class.
   This class provides much functionality (moving items, creation of  
associated nodes,
   saving and editing of associated data, cutting / copying, etc)
   @short Base class for all components/flowparts/etc
Connector -  Represents a connection between two Nodes on a ICNDocument
ICNDocument - ?  -- I suppose it's the sheet in the background
ECNode - Electrical node with voltage / current / etc properties
FPNode - You should use this node for all FlowParts. It ensures that  
connections between FlowParts are
   always valid (eg not more than two outputs from one node, which makes no  
sense)
Pin - ? -- used by the simulator
FlowPart - Base class for all FlowParts

  I have to admit that all those abbreviations in the name of the classes  
annoy me. I prefer longer, and more descriptive class names.

  Proposed changes:
Node class:
- node_type
- m_type, m_inputConnectorList, m_outputConnectorList protected members  
shall disappear
- obsolete functions: acceptInput, acceptOutput, creatInputConnector,  
*Connector* (all the members)

ECNode: (I don't like it's name, I'd prefer ElectricNode )
- type() member overridden
- protected member: connectorList
- add needed methods for connectorList: createConnector, addConnector,  
removeNullConnectors, getConnectorList, (others if needed)

new class: PinNode ( or NodePin ? :)) ), inherits from ECNode
- type() member overridden
- in its header file, define a constant equivalent to ec_pin

new class: JunctionNode ( or NodeJunction ? :)) ), inherits from ECNode
- type() member overridden
- in its header file, define a constant equivalent to ec_pin

new class: FlowNode, inherits from Node
- type() member overridden, add constant in header
- all the stuff removed from ECNode comes here

FPNode class: I'd like to rename it VerifiedFlowNode

new class: InputFlowNode, inherits from FPNode
- type() overridden & stuff

new class: OutputFlowNode, inherits from FPNode
- type() ...

new class: JunctionFlowNode, inherits from FPNode
- type() ...

... after these comes the fun to fix things that don't compile :))

  Maybe the healtiest solution would be to get rid of that type() member  
and fix the code that uses it. The problem is that it is also the hardest  
thing to do.

> Behaviorally, I've seen all kinds of strangeness, such as currents
> disappearing into nothing, and other signs that the simulation code is
> severely broken in some cases.

  I've seen too. In some cases all the voltages and currents disappear from  
the circuit, even if the circuit is valid.


   Zoltan