Java problem - help please!

[Kuciwalker]

A constructor should allocate an object and any necessary members only.

For operational things, like placing the sub in the sea, this should be done via a separate method.

Remember that the main purpose of OO code is enhanced reusability and maintenance. Muddling up the constructors with something other than simple object initialization is a no-no.

There are plenty of times when it's an acceptable or even necessary pattern for a constructor to register itself with an outside object.

This is doubly true because, unlike wrt closures, Java genuinely lacks destructors.

[Kuciwalker]

@Cort Haus, You may think that Kuci, Asher and I just have some academic brawl of what is the right method, but there is a little more in it than that.

Consider the situation where you for some reason needs a temp submarine - you use kuci's method to create that object. After doing what you want to do, you now have a ghost sub in the ocean. In C++ you will have a pointer to unallocated memory, and I guess the same goes for java, though, I'm not sure - no matter what, you have pointers to invalid data.

Except that the constructor I wrote requires a Sea as a parameter. If you want to make temporary submarines then you create a no-arg constructor. Duh.

[BlackCat]

Except that the constructor I wrote requires a Sea as a parameter. If you want to make temporary submarines then you create a no-arg constructor. Duh.

Kuci, you are really funny. How do you suggest that a temp sub without knowledge of it's ocean should be of any value ?

Why don't you just admit your failure so we can point fingers at you in the future ?

Edit: and laughing, of course

[BlackCat]

A constructor should allocate an object and any necessary members only.

For operational things, like placing the sub in the sea, this should be done via a separate method.

Remember that the main purpose of OO code is enhanced reusability and maintenance. Muddling up the constructors with something other than simple object initialization is a no-no.

There are plenty of times when it's an acceptable or even necessary pattern for a constructor to register itself with an outside object.

This is doubly true because, unlike wrt closures, Java genuinely lacks destructors.

You may have that kind of perversity in java, but certainly not in C++. Besides that, I honestly don't understand why you think that secretly adding objects is a good thing - that is against all good programming rules.

[Kuciwalker]

Kuci, you are really funny. How do you suggest that a temp sub without knowledge of it's ocean should be of any value ?

If a temporary sub has a Sea, and in order for the relevant commands to be process must be registered with that Sea (which is at least the case for moveTo), then it would be improper to create it without registering it.

[Asher]

What if a sub went into drydock?

[Kuciwalker]

If you have more containing location types than just Seas (god damn it THE ATLANTIC OCEAN IS NOT A SEA) then he should have a superclass or superinterface to represent that

Or, you can represent drydock as being part of the adjacent sea.

But right now, it appears that if a Submarine needs a reference to a containing Sea, then that Sea needs a reference to the Submarine, and therefore it is proper to register the Submarine with that Sea as soon as it learns which Sea it's in.

[Asher]

I don't think a Submarine object should have any knowledge about which sea it's in.

The sea should have a list of submarines, the submarine should not have an attribute defining sea.

[BlackCat]

If a temporary sub has a Sea, and in order for the relevant commands to be process must be registered with that Sea (which is at least the case for moveTo), then it would be improper to create it without registering it.

I seriosly hope that you are joking. A termporary Sub doesn't need to know anything about what sea it is placed in - that is only nessecary if it want to check possible movements in the sea, and for that it doesn't need to exist.

What kind of mushrooms are you chewing ? They sound pretty interesting

[Kuciwalker]

I don't think a Submarine object should have any knowledge about which sea it's in.

The sea should have a list of submarines, the submarine should not have an attribute defining sea.

This doesn't work, as per the OP, because the submarine has to know what Sea it's in if it wants to know where it can move.

You could give it a reference to a global object that contains a list of all the seas, but that is functionally pretty similar.

[Kuciwalker]

I seriosly hope that you are joking. A termporary Sub doesn't need to know anything about what sea it is placed in - that is only nessecary if it want to check possible movements in the sea, and for that it doesn't need to exist.

DO YOU EVEN READ YOUR OWN POSTS. JUST FIVE POSTS EARLIER YOU WROTE:

Kuci, you are really funny. How do you suggest that a temp sub without knowledge of it's ocean should be of any value ?

So which is it, halfwit, do temporary subs need to know their containing Sea? If so, you use the constructor that takes a Sea parameter. Or do they not need to know? If that's true, just use a no-arg constructor. PICK ONE.

[BlackCat]

You could give it a reference to a global object that contains a list of all the seas, but that is functionally pretty similar.

BS. All that a global Sub needs is a refererece to wich sea it is in.

[Kuciwalker]

OH HEY GUESS WHAT THAT'S EXACTLY WHAT I WAS ADVOCATING

[Kuciwalker]

OK, BlackCat is going on ignore. He is actually thicker than curtis, who can at least read most of the time.

[BlackCat]

Kuci, I'm really glad to hear that - no more listening to your lack of knowledge will be pure harmony

It's actually quite funny, I have kicked you in the ass twice in the last couple of days and your answer is putting me on ignore