On Tue, 08 Jul 2008 21:55:58 +0200, Alan Grimes <[EMAIL PROTECTED]> 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 ------------------------------------------------------------------------- Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 _______________________________________________ Ktechlab-devel mailing list Ktechlab-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ktechlab-devel
