This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
from Joshua Bloch's Effective Java, page 167, The form beginning with �get� is mandatory if the class containing the method is a Bean [JavaBeans], and it�s advisable if you�re considering turning the class into a Bean at a later time.
What's a Bean?!
I've heard it takes forever to grow a woman from the ground
Joseph, A "Bean" in this context is a Java class that conforms to the JavaBeans specification. The specification defines how methods should be defined so that they can easily be integrated into other applications. It goes into detail about how properties should have a getProperty() and setProperty() methods. If the property is a boolean property, it can have setProperty() and isProperty(). There are other things is specifies that have to deal with indexed properties, restricted properties, and some other stuff. The whole idea is to have a pluggable class (aka "Bean") that can be used by any number of other applications that use classes (aka "Beans") that conform to this specification. You can find the JavaBeans specification on Sun's Java website if you're interested in all the details.
No, it's not an interface per se, it's just an implementation pattern that has been formalized. If you stop an think about it, all (or at least most) objects should follow the "Bean" paradigm. Beans are all about encapsulation - each data element is presented to the world through accessor methods. That is, if I have an attribute called grebneebitz, then I would have two methods: getGrebneebitz() and setGrebneebitz(). Except in these two methods, I would never access my grebneebitz attribute directly -- not even in the same class. This way, if I ever change some implementation point of grebneebitz, then all I ahve to change is my get and my set methods. (This last point has nothing to do with Beans, just about encapsulation in general...) I would do this for all attributes in my class: grebneebitz, fooBar, and isstvan. Now assume that I want to build a tool that lets the user enter a variable name and the tool will display the value of that variable. While I could, of course, build a large switch or if/else if construct, that is cumbersome from several perspectives (especially the maintenance perspective). Instead, I could use Reflection, a feature of Java that allows you to access methods in a very meta- sort of way. Thus, when I type in fooBar, the tool will retreive the appropriate value. If I type in helloWorld, the tool will either display "That variable does not exist" or will come crashing down (depending on how good the developer is, of course ). Now assume that I write this class and want to use [I]someone else's[I] tool to view these variables. Their tool needs to be able to use reflection to access my variables. Here enters the "Bean" concept. If their tool is Bean-compatable and my class is Bean-compatable, then it should have no problem reading/writing these variables. And since good Object-Oriented programming uses encapsulation (see above), the Bean paradigm insists that there be a getFoorBar and a setFooBar method in my class. So, your method would probably look like:
Piscis Babelis est parvus, flavus, et hiridicus, et est probabiliter insolitissima raritas in toto mundo.
Joined: Apr 04, 2004
Instead, I could use Reflection, a feature of Java that allows you to access methods in a very meta- sort of way.
Here, i fear, you have lost me. If Reflection is something you've explained ad infinitum, please direct me to a pre-existing explanation