[ruby-talk:01823] Re: Objects nested sometimes.

On 14 Mar 2000, Dave Thomas wrote:

> Hugh Sasse Staff Elec Eng <[e-mail]> writes:
> 
> > 	sort of thing?  I'm just a bit unsure about the instance
> > 	variables in both types -- I know I can make them public with
> > 	attr() but that creates *functions* to access them[?], so will 
> > 	that mean that the port cannot point to the parent's variables,
> > 	or not?  I will have several nodes and several ports, so it
> > 	must be the case that the voltages (for a node or a port) are
> > 	not shared across all instances of the same type (node or
> > 	port).  Hence my question about instance variables.
> 
> Well, I guess I'd probably ask "why do you want to point to your
> parent's variables in the first place".

This is a fair question. I will answer it below.
> 
> It seems to be me are two scenarios:
> 
> 1. You need the values of the voltages *at the time* the node is
>    created. In that case you'd want to copy the parent's values down.
> 
> 2. You need the *current* values of the parent's voltages. In that
>    case, why have an extra set of instance variables in the child, as
>    you can always get to the parent's values when you need to?

2 is the case here.  It is because of the coceptualisasion of the problem.

Some of the work of the node needs to be done on the voltages, as these
change with time according to other properties of the node (conductivity
for example).  So when I am working within one node I don't want to
keep banging on about "ports" in my code.

I also need to propagate the voltagas from node to node and this is 
best handled at the level of ports.  I need to keep this conceptually
simple as well. I don't want to have to sort out twelve voltages (which
by convention have memorable names like vxny, vynz) when I can have
six ports to deal with instead.
 
> 
> However, there is a third point. There's an OO design principle,
> somewhat imperiously called The Law of Demeter, which basically says
> you shouldn't go groveling around inside sub-objects, because it
> increases coupling in your code, making it more difficult to
> maintain. In this case, we have a Node, that contains a number of
> Ports. The LOD would say that
> 
>       v = aNode.getPort(1).getVoltage(2)
> 
> is bad form, because you're asking a sub-object of Node (a Port) to do 
> something. The LOD says it would be better to hide the implementation
> of Ports within Nodes by doing something like:
> 
>      v = Anode.getPortVoltage(1, 2)
> 
That makes sense, but in this case the ports are to hide the nomenclature
of the voltages, so they are a different access method to the same data.

> Now, I'm not particularly trying to push the Law of Demeter here--I
> break it every day. However, sometimes, when things start to get all
> tangled, it can help point the way towards simplifications. Perhaps
> the problems you're having are not with the storage of data, but with
> its access?

It is not so much with its access, but how to keep that access tidy
so it can be debugged later.

I have faced similar problems when I was trying to deal with images 
in the past:  Is a colour image 
   a) a single colour image
   b) 3 monochrome images one for red, one for green and one for blue
   c) a stack of 24 bitplanes
for example :-)?   It depends on what you want to do with it, but
if you need to treat it in all those ways, rules will get bent!

> 
> Now I know absolutely nothing about your problem, so this may be just
> a load of bollocks. Please ignore it if so ;-)

> 
I think I have solved it as far as I need to, now.  I have put my 
stumblings in this area at 

http://www.eng.dmu.ac.uk/~hgs/ruby/partial_nesting.rb

which may well be sub-optimal in some way, but works for me.  Maybe
this will be of help to others later.

> 
> Regards
> 
> 
> Dave
> 
	Thank you all for your help,
	Hugh
	[e-mail]