Re: newbie help
Re: newbie help
- Subject: Re: newbie help
- From: Ian Joyner <email@hidden>
- Date: Tue, 4 Jul 2006 10:47:22 +1000
On 04/07/2006, at 8:03 AM, Art Isbell wrote:
On Jul 3, 2006, at 9:01 AM, Theodore Petrosky wrote:
While adding a key to WO builder, it says that the
variable will be defined as:
protected string <stringname>;
however they come in as:
public string <stringname>;
If when you add a key in WO builder, you choose to add only an
instance variable but no accessor methods, the variable will be
declared "public" so that WO can access the variable directly. If
you choose to create at least one accessor method, the variable
will be declared "protected" because WO won't need to access the
variable directly.
Personally, I never choose to create just an instance variable
because, to me, that minimizes encapsulation and makes debugging
difficult (there's no accessor method on which to set a break point).
That's a good point about break points, although such consideration
clutters up the code with non-design considerations. A good thing
about WO is that it puts encapsulation back in by generating accessor
(get) routines for you, although they really should not be necessary,
if for every public variable 'x' an accessor 'x ()' was implied. The
clutter of '()' is also unnecessary where parameterless functions and
variables look the same, but in C-based languages, parameterless
functions need the '()'. (Doesn't the debugger have 'watchpoints',
where a breakpoint is taken when a variable is either accessed or
updated. Maybe that was only Burroughs stuff.)
I also change the instance variable declaration to "private" so
that access by any objects that aren't members of the current class
must occur via accessor methods.
The bad thing about "private" is that it hides things from subclasses
as well, which have a more intimate relationship with a parent class
than other classes. Thus I tend not to use private, but would rather
a stricter definition of protected, although inheritance hierarchies
tend to be shallow in WO, so perhaps that is a good reason for
closing things off with the stricter private, but I always like to
leave software open ended for inheritance. So in this case you have
to provide accessors as well (which is more non-design code).
However, protected in Java seems too liberal, meaning access in
current class and subclasses but a whole bunch of other things as well.
This can minimize problems caused by accessing the instance
variable directly.
I don't know enough java to understand the difference
and why there was a change from the version the books
talk about and the 5.3 that I downloaded.
It's really important to understand Java well. Learning the WO
API is daunting enough, but if you aren't confident about Java,
you'll have an even more difficult road ahead.
Yes, so read the Java Language Specification well, and particularly
Chapter 6 on Access control, but at least Java removes most of the
well-known traps which are all over the place in C and other C-based
languages (where you get underlying implementation concerns popping
up all over the place, often in unexpected and catastrophic ways).
Basically, what access control is about is defining in a class what
is design and what is implementation. The public spec says this is
part of your classes API and thus is the design seen from other
objects. Protected says something is not part of the API and thus
implementation, except that you might have a single concept broken
down into a small set of cooperating classes, which Java would expect
put into a single package, except it is sometimes difficult to
arrange this exactly as you would like along package boundaries.
Anyway, the important thing about accessors is to consider the design/
implementation divide. Use WO to do the design and let it generate
the implementation stuff for you automatically.
HTH
Ian
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden