Re: Passing by reference

H. S. Lahman wrote:
Responding to Veeneman...

Is passing a method argument by reference inherently dangerous?

It depends upon the reason one is passing the reference. One can't
instantiate all relationships via a constructor so there will always be
a need for passing an object reference to instantiate conditional
relationships of relationships where participation varies depending on
context. So passing an object reference solely to instantiate a
relationship is not Bad simply because it is sometimes unavoidable.

However, passing object references is generally not a good idea in any
normal solution collaboration.

<snip detailed explanation of the above>

I've been mostly lurking here for some time, and am finally beginning
to grok what you're getting at here (this being the third or fourth
reply of yours on this topic which I have read). I'll have to
re-evaluate some of the code I've recently written to see how many
relationships are being instantiated via the passing of a reference
before it really sinks in, but the reasoning does make sense to me.

But I'm still missing some puzzle pieces.

In your list of the degrees of coupling, you mentioned
data-by-reference arguments as being distinct from object-by-reference
arguments. What distinguishes the two? I am by no means an OO expert,
but when I read about Alan Kay's original vision of Smalltalk, for
example, I don't see where the concept of 'data' fits into the picture.
My understanding is that even the integers were envisioned as instances
of objects, like tiny computers, sending and receiving messages. That
the basic data types in Java exist was, I thought, essentially a
performance-driven compromise. Or do you mean data as in 'value type,'
like Java's String, Integer, etc.? If so, what allows us to treat these
objects any differently from other objects in our design? (I don't mean
to suggest that we *should* treat them the same, I just don't
understand why an immutable object is all *that* different from a
mutable one)

I would also be very interested to hear more about 'knowledge
accessors.' What sorts of characteristics and/or constraints
distinguish a knowledge accessor from a more typical method? Living in
the Java world, I naturally think of 'getter' methods as 'knowledge
accessors,' and have lately come to the conclusion that the presence of
getter methods (the way they are typically used) is in most cases
violating encapsulation and a symptom of misplaced responsibilities. In
my current project at work, I have only found the need for 'getter'
methods on the lowest-level domain objects in the problem space, and
these objects are so far little more than data containers with some
basic validation and consistency checks. The presence of the 'getters'
and the lack of any substance in these low-level classes makes me think
I must have comitted some sort of design sin.

Are my logic-starved low-level objects more like data to be passed
around than objects with collaborations, or am I simply missing some
point entirely?

Any thoughts would be welcome,
-Matt McGill

.

Relevant Pages

  • Re: Newbie: access function of Form1 from Form2
    ... This is usually done by passing it as a property value or as a procedure argument. ... Wouldnt it be an overkill to instantiate a new form1 as New myProject.Form1? ... reference to the existing instance. ...
    (microsoft.public.dotnet.languages.vb)
  • Re: pointer syntax
    ... > really passing a reference (which is like an old-school pointer, ... > a copy of the primitive's value and passing that. ... build them yourself with pointers. ... mean a var parameter, write a var parameter. ...
    (comp.lang.pascal.delphi.misc)
  • Re: Using ref
    ... the address of a variable that contains a reference to an object, ... the C version is passing the address of a variable that contains the   ... Inasmuch as the specification is unambiguous, there is a single truth. ... Every time he states the incorrect view, I will feel compelled to correct his incorrect statements. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: calling from one workbook the classes and functions in another
    ... having discovered the vb trick recently I'm suddenly a big fan ... > reference to the instantiated class. ... you can't instantiate the class. ... >> Copy your cls into a VB Project for an activex dll. ...
    (microsoft.public.excel.programming)
  • Re: Design question: Multiplying singletons
    ... Since relationship implementation is orthogonal to class semantics and it is usually easy to implement when originally defining objects, it is usually a good ideal to implement the *-side of such relationships and instantiate them properly even if there is no immediate need to navigate them. ... but not as much to keep the reference to the whole in the ... through the AController object. ... One could use a factory like AController to instantiate the relationships dynamically, ...
    (comp.object)