Win a copy of Think Java: How to Think Like a Computer Scientist this week in the Java in General forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

To Bean or Not To Bean...

 
Dale DeMott
Ranch Hand
Posts: 515
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Okay... so I'm reading through all my books and all my manuals (many as they are) and I see bean used many times through out the books. It has been used in many contexts. How exactly is BEAN supose to be used??? Can someone please explain this to me?
 
Joel McNary
Bartender
Posts: 1840
Eclipse IDE Java Ruby
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It depends on what is meant by a "Bean" Beans come in two flavors (and many sub-flavors):
1). Java Beans
2). Enterprise Java Beans
A Java Bean is defined simply as any class that makes its member variable available through getXXX and setXXX methods. (Although good OO coding says to do this anyway; if you do, any instance can be thought of as a "bean" [you shouldn't, but you could].)
Theoretically, instances of these classes can have their values modified through a BeanBox (typically part of an IDE) that provides you graphical access to these attributes.
Example:
You want to place a JLabel in a GUI component. You drag-and-drop the label from the toolbar. The BeanBox creates a new instance of the lable and adds it to the container where you specified. Then a properties pane comes up, and you can edit the "Text" attribute of the label. The BeanBox knows that this attribtue is modified through the "getText" and "setText" methods of JLabel.
There are a few naming conventions that must be followed to get a BeanBox to work like this (e.g., if your attribute is "text," your get and set methods must be "getText" and "setText", not "getTheText" or some such).
Enterprise Java Beans (EJBs) are another matter entirely. The part of the name "JavaBean" is (I find) misleading: They have nothing to do with the definition of a "Java Bean". Instead, EJBs are used to create highly-scaleable, distributed applications. If your application is a large application that will be used by many people, EJBs are they way to go. (I find that the actual value of "many" seems to be diminishing). however, EJBs are meant as a back-end to Servlet/JSP-based web applciations; they can be a pain to implement in a desktop applications (typically the desktop has to communicate with a Servlet which communicates with the EJB.
 
Dale DeMott
Ranch Hand
Posts: 515
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for the reply. I did know about the EJBs, and guess I never really thought of EJBs as Java Beans. So by definition Java Beans have accessors, but typically they have an IDE attached to them as well??
 
Eric Fletcher
Ranch Hand
Posts: 188
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Dale DeMott:
So by definition Java Beans have accessors, but typically they have an IDE attached to them as well??

No, but they make information about themselves available to an IDE via something called reflection, which means another class can "look inside" the bean and "see" its accessor methods, and consequently know what the fields of the bean are by the method names, hence the naming conventions Joel mentioned.
But beans(not EJBs, I think Joel is right the name is a bit misleading) can be used for a lot of things outside of IDEs. Web apps are a common place to find beans, where they often serve as serializable data structures to pass information around. There are standard JSP tags like<jsp:useBean/> and <jsp:setProperty/> that use reflection to make it easy to manipulate and access data in the bean.
HTH
E
[ April 18, 2003: Message edited by: Eric Fletcher ]
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic