Getters which return an Iterator and defensive copies

[Tushar Goel]

But there are time where we need to give an access to the references like in case of iterators. So do we have to use defence copy in such cases
or what?

[Campbell Ritchie]

You would have to override the iterator() method to make the Iterator return defensive copies. That is only possible if you know that details of the type the Iterator returns.

Did you intend to post that question here? It seems off topic.

[Tushar Goel]

Did you intend to post that question here? It seems off topic.

No. I was thinking in respect of the getter/setter. Some times we have to return references like iterator or collection or etc....

[Campbell Ritchie]

New topic, then. No sooner said than done.

[Junilu Lacar]

I don't think it's advisable to make iterators return defensive copies. Iterators have a well defined responsibility and nowhere in the API docs does it say that the elements returned by the Iterator need to be defensive copies. Doing so would violate the Principle of Least Surprises, IMO. If you are really concerned about making defensive copies, wrap the collection up first then get an iterator from that.

[Tushar Goel]

Thanks Campbell for creating a new topic.. Sorry i should have created..

@Junilu So we should make defensive copy of collection itself which makes all other things including iterator safe.

[Junilu Lacar]

Yes, that's the idea. There are ways to make a collection immutable but I'm not sure if that would go far enough though because I believe those just prevent modification of the collection itself, not necessarily the individual elements obtained from it. You could wrap it and have the wrapper return copies of any elements accessed. That way the collection’s interface would be consistent and clients can naturally expect an iterator obtained via the wrapper to return defensive copies of the contained elements as well.

[Tushar Goel]

But dint it make the things complicated? In production environment do we follow this practice?

[Junilu Lacar]

That's a decision you have to make based on your requirements. Nobody is saying you have to do this all the time. You just have to be aware of the consequences of your design decisions and see what's best for the problem at hand. This is why it's important to unit test your code/designs and have other developers try to use your code early so you can get feedback and correct problems before you go to production.

[Tushar Goel]

Thanks Junilu and Campbell..

[Campbell Ritchie]

You're welcome