However, the question is: why should I pass a parameter in a constructor if it is used as a temporary object inside of it, probably just to get some other object from that parameter? This is a clear violation of the Law of the Demeter. If L needs a string-key to be able to be bound to a particular instance of S, why don’t ask for S directly in its constructor?

Consider a class S which has a string key.

You are designing a class L which requires a valid key to an S object.

You can design L’s constructor to take a string, but then you have the overhead of validating it.

Or, you can have the constructor take an instance of S and simple store (in a readonly field) the Key (which is already valid since it came from an existing S)

How is S is short lived, and L is long lived (funny how that worked out), then you have the exact scenario I was referring to.

When the constructor exits, there are no referneces between the Short Lived and Long Lives objects in either direction. Yes by passing the short to the long as only a stack transaction, the goals are fully achieved with no overhead.

passing a short lived object through a constructor is really confusing. Since you either have a bug because you are not clearing it or you will clear the reference later which implies that you only need the object temporarily. If you need something temporarily than that suggest that your lifetime is longer than it should be or you only need it in constructor which implies that you are doing work in constructor. I like to declare all of the fields which I get through constructor as final. Which is a hint to the reader that they are not changing and are needed for the duration of the object lifetime. On the other hand passing it in through stack implies that you will probably not keep a reference as it is a temporary thing you need to get the work done.

One “Quibble”..There is no problem per se with passing a short lived to a long lived constructor parameter. It is NO different than passing it as a parameter to ANY method.

The problem (which I believe was your intent) was keeping a reference to a shorter lived that exceeds the scope of a single call from the short lived into the long lived.

MSN

Thanks, I updated the text…

The sentence beginning para 2 is ambiguous:

>> Now I believe that each object should have
>> reference to other objects whose lifetime is
>> equal or shorter to the object.

This says to me the opposite of what I think you intend. How about replacing it with something like:

>> I believe objects should only maintain references to other objects that are longer-lived.

Or have I misunderstood again?