Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Re: Make Array Unmodifiable?

Reply
Thread Tools

Re: Make Array Unmodifiable?

 
 
Roedy Green
Guest
Posts: n/a
 
      05-31-2004
On 31 May 2004 05:50:40 -0700, http://www.velocityreviews.com/forums/(E-Mail Removed) (Ken) wrote or quoted
:

>Is there a standard approach or pattern for making an array that
>cannot be modified? I ask this in this context: I'd like to be able
>to return an array from a class method without letting the caller
>subsequently modify the array.


You don't give him the raw array. You give him an wrapper object with
means to examine the elements but not set them.

See http://mindprod.com/jgloss/immutable.html


--
Canadian Mind Products, Roedy Green.
Coaching, problem solving, economical contract programming.
See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.
 
Reply With Quote
 
 
 
 
Liz
Guest
Posts: n/a
 
      05-31-2004

"Roedy Green" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> On 31 May 2004 05:50:40 -0700, (E-Mail Removed) (Ken) wrote or quoted
> :
>
> >Is there a standard approach or pattern for making an array that
> >cannot be modified? I ask this in this context: I'd like to be able
> >to return an array from a class method without letting the caller
> >subsequently modify the array.

>
> You don't give him the raw array. You give him an wrapper object with
> means to examine the elements but not set them.


Isn't this sort of like using get/set ? If a calling method does
a get on your primitive data, like s/he gets the value for 'totalSales'
you have no control over what s/he does with it as long as s/he
doesn't damage your internal copy. Is it not the same with other data?


 
Reply With Quote
 
 
 
 
kk_oop
Guest
Posts: n/a
 
      06-01-2004
Liz gave me a follow up question.

How do you preserve encapsulation with a get method? Does the "return"
command return a reference to the internal attribute? Won't the caller
be able then to use that reference to modify the value of the called
classes attributes? Or should getter methods always be written to
return a clone?

Also, does "return" treat fundemental types (int, float, char, etc.)
differently than user defined types (classes, arrays, collections)?

Thanks again,

Ken

Liz wrote:

>"Roedy Green" <(E-Mail Removed)> wrote in message
>news:(E-Mail Removed).. .
>
>
>>On 31 May 2004 05:50:40 -0700, (E-Mail Removed) (Ken) wrote or quoted
>>:
>>
>>
>>
>>>Is there a standard approach or pattern for making an array that
>>>cannot be modified? I ask this in this context: I'd like to be able
>>>to return an array from a class method without letting the caller
>>>subsequently modify the array.
>>>
>>>

>>You don't give him the raw array. You give him an wrapper object with
>>means to examine the elements but not set them.
>>
>>

>
>Isn't this sort of like using get/set ? If a calling method does
>a get on your primitive data, like s/he gets the value for 'totalSales'
>you have no control over what s/he does with it as long as s/he
>doesn't damage your internal copy. Is it not the same with other data?
>
>
>
>


 
Reply With Quote
 
Ryan Stewart
Guest
Posts: n/a
 
      06-01-2004
> "kk_oop<no spam> @yahoo.com>" <"kk_oop<no spam> wrote in
> message news:40bbdb2e$0$3137$(E-Mail Removed)...
> > Liz wrote:
> > Isn't this sort of like using get/set ? If a calling method does
> > a get on your primitive data, like s/he gets the value for 'totalSales'
> > you have no control over what s/he does with it as long as s/he
> > doesn't damage your internal copy. Is it not the same with other data?
> >

> Liz gave me a follow up question.
>
> How do you preserve encapsulation with a get method? Does the
> "return" command return a reference to the internal attribute? Won't
> the caller be able then to use that reference to modify the value of the
> called classes attributes? Or should getter methods always be written
> to return a clone?
>
> Also, does "return" treat fundemental types (int, float, char, etc.)
> differently than user defined types (classes, arrays, collections)?


Both of you seem confused on some Java basics. These questions are better
posted to comp.lang.java.help. First, encapsulation (OO basic, not Java
specific) refers to having a well defined public interface and hiding the
details of internal implementation. Next, the types are "primitive" and
"reference", not fundamental and user defined. In answer to your questions,
when you return a reference type, you are returning a reference to an
object. The caller can do anything to that object that the object allows. To
your next question, an emphatic No! Getter methods should *not* always
return a clone. That would be ridiculously inefficient. Finally, primitive
types and reference types are treated exactly the same in assignment,
parameter passing, returning, etc. You just have to realize that a reference
is like a handle to an object. You don't pass the object itself, just a
reference to it.


 
Reply With Quote
 
kk_oop
Guest
Posts: n/a
 
      06-01-2004
My question remains. If a getter returns a reference to a class
attribute, it would seem that the caller could take that reference and
start changing the value of what it is referring to.

Let me clarify with an example. Let's say I have a class x that has a
private attribute mySize. I also have defined a public getter called
getSize. I don't want anyone outside of an instance of x to alter
mySize. x handles that internally (ie, mySize maintenance is
encapsulated). This means I would never want a caller of getSize to be
able to change an x object's internal value of mySize. The would be
disasterous for the stability of the x object's state. This is why I
say that the getter seems to break the encapsulation of mySize.

So:

1- Is my description accurate that the caller of myX.getSize( ) can take
the returned reference and use it to change the value of the private
mySize attribute?

2- What is the standard java way of preventing this for both primitive
and reference data types?

Thanks,

Ken

Ryan Stewart wrote:

>Both of you seem confused on some Java basics. These questions are better
>posted to comp.lang.java.help. First, encapsulation (OO basic, not Java
>specific) refers to having a well defined public interface and hiding the
>details of internal implementation. Next, the types are "primitive" and
>"reference", not fundamental and user defined. In answer to your questions,
>when you return a reference type, you are returning a reference to an
>object. The caller can do anything to that object that the object allows. To
>your next question, an emphatic No! Getter methods should *not* always
>return a clone. That would be ridiculously inefficient. Finally, primitive
>types and reference types are treated exactly the same in assignment,
>parameter passing, returning, etc. You just have to realize that a reference
>is like a handle to an object. You don't pass the object itself, just a
>reference to it.
>
>
>
>


 
Reply With Quote
 
Joona I Palaste
Guest
Posts: n/a
 
      06-01-2004
"kk_oop<no spam>" <"kk_oop <no spam>"@yahoo.com> scribbled the following:
> My question remains. If a getter returns a reference to a class
> attribute, it would seem that the caller could take that reference and
> start changing the value of what it is referring to.


> Let me clarify with an example. Let's say I have a class x that has a
> private attribute mySize. I also have defined a public getter called
> getSize. I don't want anyone outside of an instance of x to alter
> mySize. x handles that internally (ie, mySize maintenance is
> encapsulated). This means I would never want a caller of getSize to be
> able to change an x object's internal value of mySize. The would be
> disasterous for the stability of the x object's state. This is why I
> say that the getter seems to break the encapsulation of mySize.


> So:


> 1- Is my description accurate that the caller of myX.getSize( ) can take
> the returned reference and use it to change the value of the private
> mySize attribute?


If the type of the private mySize attribute is a primitive, no way in
heck is anyone going to alter its value if all they have is the return
value from myX.getSize().
If it's a reference type, it's slightly more complex. If the reference
value is reassigned to refer to another object, the private mySize
attribute is still safe, nothing has changed. But if the object itself
is changed through the reference, then the changes are also visible in
the private mySize attribute. It's the same object.

> 2- What is the standard java way of preventing this for both primitive
> and reference data types?


For primitive types: It's already done for you. You'd have a more
difficult time *allowing* this behaviour than preventing it.
For reference types: Just make sure the returned object doesn't have
any public methods or fields that would alter its internal state.

--
/-- Joona Palaste ((E-Mail Removed)) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"A computer program does what you tell it to do, not what you want it to do."
- Anon
 
Reply With Quote
 
P.Hill
Guest
Posts: n/a
 
      06-01-2004
Joona I Palaste wrote:
>Just make sure the returned object doesn't have
> any public methods or fields that would alter its internal state.


Hence, this is exactly why String objects are immutable.
It wouldn't be so cool, if for example, the value inside a
String used as a key in a hashtable was manipulated while it
was still supposed to be the key value. It might, or should
I say, mostly likely, result in very strange results.
immutable objects thus are a very useful pattern in Java
software and also why Java is so good at garbage collecting
small young objects, since you can produce lots of them in
very important and functionally useful situations.

-Paul

 
Reply With Quote
 
Liz
Guest
Posts: n/a
 
      06-01-2004

"P.Hill" <(E-Mail Removed)> wrote in message
news:c9iba0$pbq$(E-Mail Removed)...
> Joona I Palaste wrote:
> >Just make sure the returned object doesn't have
> > any public methods or fields that would alter its internal state.

>
> Hence, this is exactly why String objects are immutable.
> It wouldn't be so cool, if for example, the value inside a
> String used as a key in a hashtable was manipulated while it
> was still supposed to be the key value. It might, or should
> I say, mostly likely, result in very strange results.
> immutable objects thus are a very useful pattern in Java
> software and also why Java is so good at garbage collecting
> small young objects, since you can produce lots of them in
> very important and functionally useful situations.
>
> -Paul
>


What sort of users do you have that are going to screw around
with your hidden data? Didn't you make it clear that they can't do this?
And if they do, they have no recourse to blame you for their misuse.


 
Reply With Quote
 
Liz
Guest
Posts: n/a
 
      06-01-2004

"Liz" <(E-Mail Removed)> wrote in message
news:bE4vc.32103$eY2.7683@attbi_s02...
>
> "P.Hill" <(E-Mail Removed)> wrote in message
> news:c9iba0$pbq$(E-Mail Removed)...
> > Joona I Palaste wrote:
> > >Just make sure the returned object doesn't have
> > > any public methods or fields that would alter its internal state.

> >
> > Hence, this is exactly why String objects are immutable.
> > It wouldn't be so cool, if for example, the value inside a
> > String used as a key in a hashtable was manipulated while it
> > was still supposed to be the key value. It might, or should
> > I say, mostly likely, result in very strange results.
> > immutable objects thus are a very useful pattern in Java
> > software and also why Java is so good at garbage collecting
> > small young objects, since you can produce lots of them in
> > very important and functionally useful situations.
> >
> > -Paul
> >

>
> What sort of users do you have that are going to screw around
> with your hidden data? Didn't you make it clear that they can't do this?
> And if they do, they have no recourse to blame you for their misuse.
>

Maybe you should just call System.exit() if they change it.



 
Reply With Quote
 
Ken
Guest
Posts: n/a
 
      06-01-2004
Joona I Palaste <(E-Mail Removed)> wrote in message news:<c9huov$5ms$(E-Mail Removed)>...
> "kk_oop<no spam>" <"kk_oop <no spam>"@yahoo.com> scribbled the following:


> For reference types: Just make sure the returned object doesn't have
> any public methods or fields that would alter its internal state.


So would a typical approach be to define an interface for the class
that contained only the readonly methods, then use this as the return
type for the getter? This way I'd be returning the encapsulated
instance, but the client would only be able to access it via the
readonly interface. So it would be something like this:

public interface Class1ReadOnlyInterface
{
public int getThis();
public float getThat();
}

public class Class1 implements Class1ReadOnlyInterface
{
public int getThis()
{ ....... }

public float getThat()
{ ....... }

public void changeThis(int x)
{ ....... }

public void changeThat(float x)
{ ....... }

private int mthis;
private float mthat;

}

public class Class2
{
public Class1ReadOnlyInterface getClass1()
{
return theClass1;
}
...

private Class1 theClass1;
...
}

Is that right, or is there a simpler standard approach? I'm not
looking to reinvent the wheel here. I just figure this must not be an
unusual situation, so I'm just looking for an "accepted" way of
handling it.


Thanks again,

Ken
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
FAQ 5.9 How can I make a filehandle local to a subroutine? How do I pass filehandles between subroutines? How do I make an array of filehandles? PerlFAQ Server Perl Misc 0 01-12-2011 11:00 PM
const and array of array (of array ...) Mara Guida C Programming 3 09-03-2009 07:54 AM
How to make an array of hashes to a single array with all thevalues of these hashes ? kazaam Ruby 12 09-13-2007 01:30 PM
Uniform vector class, inheriting from Array: How to make sure thatmethods return a Vector and not an Array? Thomas Ruby 7 05-23-2005 04:21 PM
Length of Array of Array of Array Tom Perl Misc 3 12-20-2004 05:23 PM



Advertisments