In addition to the hooks argument (lets you facade classes), there's the JavaBeans argument.
If all your var's are accessed via get/set, then another app/library can use reflection to determine which vars you want people to access, and then on top of this can use the hooks to do fancy stuff - e.g. stuff which you want to do to almost ALL classes, e.g. persistence.
The examples I encounter most often are persisting data to a database and object-serialization for network transfer. In both these cases it's rather nice when you have a library which can transparently create stubs for you that e.g. read the data from the DB whenever it's needed (by overriding the methods).
However...I'm suffering a backlash against get/set's at the moment simply because of their long-windedness. It's all NIO's fault
(note: NIO breaks Sun's own recommendations / coding conventions in this regard; it simply ignores the whole get/set thing). If you want to get the limit of a buffer, you use "limit()", if you want to set the position you use "position( int )", or "position()" to get it. You soon get used to reducing your typing by 2 to 4 chars for every access (normally you have to type at least "g" and sometimes the "et" as well before hitting your autocomplete button to get you to where you can start typing the variable name).
This is particularly obvious on short var names - like "a". If you have methods or vars somewhere in your environment (e.g. all public members of imported classes) called "gabby" and "gershwin", then to type "getA()" you need to type five chars minimum. If you just used "a()" then you only need type 2. That's a big difference when writing data-manipulation classes! (especially controllers and views).