Re: An interview question

On Sat, 28 May 2005 18:49:15 +0800, Ross Bamford wrote
(in article <1117277355.8089.30.camel@xxxxxxxxxxxxxxxxx>):

> On Sat, 2005-05-28 at 17:37 +0800, steve wrote:
>> On Sat, 28 May 2005 07:50:40 +0800, Richard Wheeldon wrote
>> (in article <d78bfl$c3l$1$8302bc10@xxxxxxxxxxxxxxxx>):
>>
>>> steve wrote:
>>>>> Returning the name without doing a copy is OK because the String class
>>>>> is
>>>>> immutable. Likewise, a deep copy of the citiesVisited array is
>>>>> unnecessary.
>>>
>>> But you do need to copy the array in the constructor.
>>> Otherwise:
>>>
>>> String[] citiesVisited = new String[] { "Amsterdam", "Paris" };
>>> Person p = new Person("Fred", citiesVisited);
>>> citiedVisisted[0] = "London";
>>>
>>>> er some one ain't too smart.
>>>> you forgot about stopping "cloneable"
>>>
>>> Sorry. I don't get this. Can you please explain ?
>>>
>>> Richard
>>
>> sorry should have said using reflection, but you can always try to get
>> round
>> it by extending the class.
>>
>> to really *** it up change it to this :
>>
>>
>> public class ImmutablePerson {
>>
>> /** Name of the Person */
>>
>> private final String name;
>>
>> /** Cities he/she has visited */
>>
>> private final String[] citiesVisited;
>>
>> public ImmutablePerson(final String n, final String[] cities) {
>>
>> this.name = new String (n);
>>
>> this.citiesVisited =new String[]( cities);
>>
>> }
>>
>> /**
>>
>> * Accessor for citiesVisited
>>
>> * @return Returns the citiesVisited.
>>
>> */
>>
>> public String[] getCitiesVisited() {
>>
>> return new String[](citiesVisited);
>>
>> }
>>
>> /**
>>
>> * Accessor for name
>>
>> * @return Returns the name.
>>
>> */
>>
>> public String getName() {
>>
>> return new String (name);
>>
>> }
>>
>> }
>>
>> now when it is initted the internal variables will be set in stone, you can
>> only init a final once.
>> making the variables private does not always make them immutable.
>> and passing in/out references to objects does not make them immutable.
>>
>
> Absolutely it does, /all else being equal/. The facilities Reflection
> provides to access these members are 'Over and above' and one should not
> design to prevent such usage.
>
> The whole point of the various modifiers is to allow us to design a
> proper object-oriented system where certain things are made available
> and other things are not. The fact that the JVM provides a 'back-door'
> for those who would use it should not influence your design at all.
i might not want a "back-door"
>
> Too much code seems to come designed to be used outside normal OOP
> practices these days. Design it to work right in it's own element, and
> let someone else worry about working it in theirs.
>
>> now you cannot reflect it or extend it, and it generates new copies of the
>> variables, so now it is immutable.
>>
>> and it should be fairly bomb proof.
>>
>>
>
> Bomb proof? You do realise that you new String(n) call, for example,
> actually reuses the byte array in most cases anyway.

strings are immutable.

The private members
> are all easily accessible via reflection given appropriate permissions,
> and so on. None of this matters really - that's my point.
they are accessible but not changeable. ( FINAL!!!!)

>
> IMHO this kind of thing arises from poor definition of what 'protecting
> implementation' really means. You're not trying to protect from other
> malicious people - that is a function of some higher layer - but from
> misinformed, incorrect, and unreliable usage.
>
>

you obviously show a poor understanding of the subject being discussed.
the overriding point is this



1. Change the following code so an instance of Person is immutable
once created, it does not state that it has to be GOOD "OO" design.



2. the =new String[]( cities);, was thrown in there for a response
provoker.

3. you state the private members are accessible, via reflection, yes they
ARE.

BUT YOU CANNOT CHANGE THEM ONCE THEY ARE INITTED, BECAUSE I MADE THEM FINAL.
if you only make them private, they CAN BE CHANGED.

also by the way , strings are immutable by design., that is they get a new
copy made each time.
in reality i DO NOT NEED TO DO =New String (x);
but for clarity i do.

actually the class can still be extended, even though i stated it could not.

also define 'malicious', say you are writing part of a banking security
routine?

the above code is a A LOT more stable, both from a usage and an extension
point of view, as well as maintenance.





consider the following:

public class notimmutable{
private final Point thevalue;
{
public notimmutable( final Point Value){
thevalue=value;

}
public Point getValue(){
return Value;

}
}

this looks immutable , but it is NOT. , even with the :
private final Point thevalue;

.

Quantcast