[Ktechlab-devel] 74164 shift register.

[Julian Bäume]

Hi,

On Tuesday 28 April 2009 06:07:25 Alan Grimes wrote:
> I started to implement the part then I remembered that I wanted to
> re-design the parts library.
This needs some work, indeed.

> >>> there are still many classes stacked on top of each other (in the
> same files. If all the classes in the file are tiny, then OK. If there
> are two or more decent sized classes in a single file THEY SHOULD BE
> SEPARATE!!!!
That's true. I'm not sure if it's worth the effort to change this. I think, 
mostly this happened, because some classes started as small helper classes and 
grew larger. In fact, this isn't a good  OO design.

> There are many many advantages to keeping classes separate, for one
> thing it becomes easier to audit which classes a class is using. In one
> case I found a class including a bunch of child classes when it should
> have included only a parent class. By cleaning up includes we also
> improve compile time and the reliability of our builds.
+1

> Fortunately, ktechlab is shaping up to have several discreet layers of
> organization. These layers should be made more distinct and the
> separation between them should be rigorously enforced. Ie, most code in
> /src should be completely ignorant of anything and everything going on
> in either /src/electronics or /src/flowparts. This way the code becomes
> more robust and maintainable.
Indeed. You call them discreet layers of organisation, I'd call it 
"components" (components in an OO fashion, not electronic components). 
KTechLab should be able to run, even if one component is missing. In fact, 
there's no sense in running KTechLab without a visualisation component, but it 
should be possible. As you stated, this will lead to more robust and 
maintainable code. Just think, we could have more then one simulation 
component, may be with different intentions (one optimised for HF simulation, 
..)

> In general there should not be any super huge or super tiny classes.
> Some of the super tiny classes might be better treated as structs or
> even switch to library functionality.
That's another indicator for good/bad design. Having quite a few equally sized 
classes is an indicator for a good design.

> One of the reasons its difficult to debug the simulation engine is that
> I messed up the current reading code from the wires. =P (Yes it's my
> fault too.) But to get it working again I need a traceable path from the
> engine through the model classes (pin and wire, I think), to the
> interface classes such as electricconnector and ECNode.
I haven't looked into the KDE3 code for a while, so I'm afraid I can't help 
here much. May be I can find some time to have a closer look, but I need to 
get some stuff finished before that.

bye
julian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 489 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/ktechlab-devel/attachments/20090428/7c43967c/attachment.sig>