wood burning stoves 2.0*
The moose likes Beginning Java and the fly likes Bean?! Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "Bean?!" Watch "Bean?!" New topic
Author

Bean?!

Nick George
Ranch Hand

Joined: Apr 04, 2004
Posts: 815
1.
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
Nathaniel Stoddard
Ranch Hand

Joined: May 29, 2003
Posts: 1258
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.


Nathaniel Stodard<br />SCJP, SCJD, SCWCD, SCBCD, SCDJWS, ICAD, ICSD, ICED
Nick George
Ranch Hand

Joined: Apr 04, 2004
Posts: 815
is it anything like an interface? obviously, no methods are being directly defined by 'implementing' bean, but would i have Bean as a parameter?
something like:

What does a "pluggable" bean mean?
Joel McNary
Bartender

Joined: Aug 20, 2001
Posts: 1817

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:

Make sense?


Piscis Babelis est parvus, flavus, et hiridicus, et est probabiliter insolitissima raritas in toto mundo.
Nick George
Ranch Hand

Joined: Apr 04, 2004
Posts: 815
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
Dirk Schreckmann
Sheriff

Joined: Dec 10, 2001
Posts: 7023
You might like to take a look at the Reflection Trail of Sun's Java Tutorial.


[How To Ask Good Questions] [JavaRanch FAQ Wiki] [JavaRanch Radio]
 
wood burning stoves
 
subject: Bean?!
 
Similar Threads
Sending data via java class
struts-html:checkbox default checked
Confirm message on submit
JSF validator problem
Annotating a Session Bean