Why? What is the relationship between Robot and Computer that the
references model? Does that relationship really need to be created at
the time the Robot and/or Computer is created?
Can a computer not be moved to another computer?
Are the Robot and Computer really separate entities, or does a Robot
have a Computer aspect to it ... e.g., by implementing a Computer
interface?

"Computer" sounds more generic than something that inherently knows
about a Robot.

I have this problem with MVC all the time :)

/L

On Sun, 28 Oct 2007 13:42:05 -0700, Daniel Pitts
<newsgroup.spamfilter@virtualinfinity.net> wrote, quoted or indirectly
quoted someone who said :

There is a similar problem of calling virtual methods in constructors
that may access uninitialised (but zeroed) fields.

I think what Java aims to do is prevent you from doing anything that
will crash the JVM. However, you are free to write programs that give
meaningless results.

The idea is they will put in a safety net whereever it is easy to do
so, but feel no guilt about allowing you to write silly code.

The problem is not in whether operators are atomic or not. Clearly public
operations have to honor object invariants. The problem is the language
design and improper construction model of. While being constructed the
object does not yet exist, hence a call to *any* its public method is
illegal. As simple as that. When the specific object is constructed you can
call any *specific* method, but it is still illegal to call any
*dispatching* ones, any method potentially dispatching from inside. Only
when the polymorphic object is finally constructed one can dispatch. This
is the semantics of construction of a class instance, which you should
mentally map onto an [admittedly inconsistent] implementation of in the
given programming language (like C++ or Java).

No such thing can exist. It is as above. A reference may not exist before
the target object. And the target object does not before construction.
Hence, there cannot be any circular references upon initialization. Your
problem is that semantically, you take a raw pointer (to specific object)
and then cast it to a reference to a polymorphic object. That is
semantically illegal, even if the compiler does not tell you so.

Then one object should be able to live without another. That would break
the circle. You first create, say, computer without any robot and then
attach a robot to it. Further, a robot should be functional when its
computer has no robot attached.

However, circular dependencies usually indicate a design problem. Perhaps
you should reconsider your design.

yes...not sure about the static factory bit...but lets leave it.

hmmmm

it is 'logically valid' to consider objects with circular references
the problem, as you say comes to construction.....I need to create my
chicken and egg at the same time.....which I clearly can't.

But the problem in some sense is not an OO one....it's a real world
one....see below....

your robot, computer examples is quite nice.....

but if I were to create a robot and a computer in the real world how
would I do it? At what point does it become a robot?

In the real world I would create a mechanical robot chassis.....and
then add a computer to it....i.e. the construction of a 'robot'
requires a constructed computer....in the real world the computer does
not have to be embedded in a robot...so why would you do this in
software.

interface IComputer
{
.... bla....
}

class Robot : IRobot
{
   public Robot(IComputer computer)
   {
       ....bla....
   }
}

Responding to Pitts...

I would rephrase the first sentence. It is bad practice to instantiate
relationships with other objects if the object in hand is not properly
initialized. Generally we use factory objects to manage instantiation
for two reasons.

The first is to encapsulate the business rules and policies of
instantiation because those rules and policies are likely to be
different than those governing collaboration within the problem
solution. A corollary is that the factory object's /only/ business with
the object is instantiation. So invoking other methods on the object
should not be an issue and should be easily enforcible with good naming
conventions and peer reviews.

A second, related reason is that we can control when the object's
relationships are instantiated. One practice the factory can enforce is
that the object is fully initialized prior to instantiating any
relationships. That way no other object has access to the object until
it is properly prepared for collaboration.

A corollary is that a factory method provides a scope that is more
manageable. Thus when concurrency is an issue one only needs to block
around the scope of the factory method, which is is usually <relatively>
easy to do and can be mapped readily into distributed environments. So
long as the object is instantiated, fully initialized, and all its
relationships are instantiated within the scope of the factory method,
referential and data integrity should be a minor issue.

Conversely, as soon as initialization and/or instantiation of
unconditional relationships is split among multiple object methods, one
is in a Pandora's Box situation and the developer must take special
precautions in the OOA/D to ensure that referential and data integrity
is not violated. Generally such situations are quite fragile, especially
during maintenance, so OO reviewers are going to want a lot of
justification for not encapsulating all the instantiation in a single
method.

BTW, I don't see why one needs static factory methods or what using a
'this' pointer outside constructors has to do with this issue.

First, I am not sure why the computer hardware is being modeled in a
game simulation(?)

But, assuming there is a reason for that, let's ge a bit more specific:

[Robot]
   | 0..*
   | controls
   |
   | R1
   |
   | 1     1   R2 contains 1
[Computer] ----------------- [Memory]
   | 1
   | located in
   |
   | R3
   |
   | 1
 [Bus]

Here the unconditional nature of the R2 and R3 relationships requires
that all three objects be instantiated and the relationships are in
place before any collaborations with any of them. One likely approach
would be to have a single ComputerFactory::create method that
instantiates all three objects and their relationships within its scope.
In C++ (I don't do Java) that method might look something like:

ComputerFactory::create
{
   Computer* myComputer;
   Memory* myMemory;
   Bus* myBus;

   // get any attribute values needed for initialization

   // instantiate objects
   myComputer = new Computer; // with any attribute values
   myMemory = new Memory;     // with any attribute values
   myBus = new Bus;           // with any attribute values

   // instantiate relationships
   myComputer->setMemory(myMemory);
   myComputer->setBus(myBus);

   return myComputer;
}

If instead the objects are instantiated in separate methods, then you
need to be very careful that there is no way to collaborate with any of
them until they all have been instantiated. One way to ensure that would
be to instantiate R2 and R3 in the last factory method in the sequence.
[Just make sure nobody changes the sequence during maintenance! That's
why such instantiation is fragile.]

Now the R1 relationship conditionality requires that a Computer be
available when a Robot is instantiated, but doesn't require a Robot to
be around when a Computer is created. So we could use
RobotFactory::create to create the Robot instance and instantiate R1.
But we would have to provide that method with the proper Computer
reference, which implies that we need to invoke ComputerFactory::create
before RobotFactory::create.

Bottom line: the conditionality of the problem space relationships
usually dictates how the instantiation should be handled.

*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development".  Email
info@pathfindermda.com for your copy.
Pathfinder is hiring:
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH