🚀 go-pugleaf

private is crazy in the context if hiding a method from yourself.

My code is robust, but I dont define robust as handling all possible things
which can be thrown at it.  I choose to avoid certain things rather than
handling them.  This is one.  I would rather he not be able to change an
object which I am managing internally.

Especially considering this is a peroperty VETO, then one could just take
the object and minipulate it to what they want anyway, and not even fire any
change event.  I wont have to check for null images if I dont allow them to
be set.  This is what I am trying to do here.  But I wasnt sure if passing a
copy was good practice or not.  I am now passing a copy though anyway.


The setImage(ImageIcon x) method does throw an exception if you pass in a
null value.  However, if you get ahold to the ImageIcon and call

icon.setImage(null), you will wipe out the internal image, and my program
will be unhappy.  Thats my point from above.



"Rich Wilkman" <richw@formlessvoid.com> wrote in message
news:3B3A10A0.864A0F91@formlessvoid.com...
> At a minimum you should make your code robust enough to take bogus
> values and nulls from the user and either defang them or put your image
> back.
>
> I don't understand why "private" is crazy, though.  Data hiding and
> limiting access is quite good.  I have plenty of beans with private
> members, public getters but only package local setters.  That makes
> things a little easier on my side and provides a good level of
> protection and visibility for the client.
>
> -Rich
>
> dnoyeB wrote:
> >
> > Well yea, when its my code.  But this is a bean, and the end user may
get
> > happy and start fiddling around with the innards of the object I pass
back.
> > Its crazy I know, but so is using "private."  Its an ImageIcon, he could
> > easily replace the image itholds, or set its internal image to null.  My
> > bean would not like that.  Thats why im considering the copy.  ImageIcon
> > does not have a copy constructor though...
> >
> > "John McGrath [TeamB]" <ng-b@JPMcGrath.net> wrote in message
> > news:MPG.15a34d4ad4cde13a98a2e5@forums.borland.com...
> > > On Tue, 26 Jun 2001 15:12:10 -0400, "dnoyeB" <lamont_gilbert @
> > > rigidsoftware.com> wrote:
> > >
> > > > HOwever, I am concerned about passing the old object reference
> > > > into this event to be handed around and molested/violated.  I
> > > > would prefer to pass a copy of the object, but is this proper?
> > >
> > > I do not think you have to create a copy, but there is no reason that
> > > it would not work.  Well behaved code should probably not be changing
> > > the objects passed to it in a property change notification, so I do
not
> > > think it is really necessary in most cases.  Depending on how many
such
> > > events are generated, it could become a performance issue if you copy
> > > the object.
> > >
> > > --
> > > Regards,
> > >
> > > John McGrath [TeamB]
> > >
> > > ---------------------------------------------------
> > > Before sending me e-mail, please read:
> > >     http://www.JPMcGrath.net/newsgroups/e-mail.html