• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: newbie help
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


References: 
 >newbie help (From: Theodore Petrosky <email@hidden>)
 >Re: newbie help (From: Art Isbell <email@hidden>)

  • Prev by Date: Re: Locations of resources ye again
  • Next by Date: Re: newbie help
  • Previous by thread: Re: newbie help
  • Next by thread: Re: newbie help
  • Index(es):
    • Date
    • Thread