| Lesson 3 | Bean methods |
| Objective | Learn about Bean methods. |
JavaBeans Method Encapsulation
Like a normal Java class, a Bean is capable of having methods with different types of access.
For example, private methods are accessible only within the internals of a Bean, whereas protected methods are accessible both internally and in derived Beans. The most important methods for Beans are public methods, since they form the primary means by which a Bean communicates with the outside world.
For example, private methods are accessible only within the internals of a Bean, whereas protected methods are accessible both internally and in derived Beans. The most important methods for Beans are public methods, since they form the primary means by which a Bean communicates with the outside world.
Bean methods form Interfaces
Public Bean methods are often grouped according to their function, in which case they form interfaces.
Beans expose their functionality to the outside world throughinterfaces.
Interfaces[1] are important because they specify the protocol by which a particular Bean is interacted with externally. A programmer need only know a Bean's interfaces to be able to successfully manipulate and interact with the Bean.
Interfaces[1] are important because they specify the protocol by which a particular Bean is interacted with externally. A programmer need only know a Bean's interfaces to be able to successfully manipulate and interact with the Bean.
Interface Definition
Interface: a functionally related group of public methods. In the next lesson, you learn about properties and their relationship to the internal state of Beans.
Java Event Model
The JavaBeans architecture takes advantage of the event model that was introduced in version 1.1 of the Java language.
Beans are treated the same as every other object within the event model. In fact, there is nothing at all about the event model that is specific to Beans.
The Beans component model is designed to take advantage of features that are already available in Java. In many cases the features that are needed by Beans are generic enough to be provided by a core Java class library, making them available to any Java class whether or not it happens to be a Bean.
An event source object sends a notification that an event occurred by invoking a method on the target, or "listening," object. The notification mechanism uses standard Java methods. There is no new language construct or programming syntax required to create such a method. Every event has a specific notification method associated with it. When the event occurs, the associated method is invoked on every object that is listening for it. The method itself describes to the caller which event has taken place. When this method is called, an object is passed as an argument that contains specific information about that particular instance of the event. This object always contains a reference to the object that was the source of the event. In addition, it allows the object receiving the event to identify the sender, and is particularly important if an object listens for the same event from several sources. Without this reference, we would have no way of determining which object sent the event and the combination of the method called and the data sent completely defines the event.
The Java event model is comprised of event objects, event listeners, and event sources. These objects interoperate in a standard way, using method invocation to facilitate firing and handling events. The event listener registers itself with the event source to receive event notifications. At some point the event source fires an event with the event object as a parameter, and the event listener handles the event.
The Beans component model is designed to take advantage of features that are already available in Java. In many cases the features that are needed by Beans are generic enough to be provided by a core Java class library, making them available to any Java class whether or not it happens to be a Bean.
An event source object sends a notification that an event occurred by invoking a method on the target, or "listening," object. The notification mechanism uses standard Java methods. There is no new language construct or programming syntax required to create such a method. Every event has a specific notification method associated with it. When the event occurs, the associated method is invoked on every object that is listening for it. The method itself describes to the caller which event has taken place. When this method is called, an object is passed as an argument that contains specific information about that particular instance of the event. This object always contains a reference to the object that was the source of the event. In addition, it allows the object receiving the event to identify the sender, and is particularly important if an object listens for the same event from several sources. Without this reference, we would have no way of determining which object sent the event and the combination of the method called and the data sent completely defines the event.
The Java event model is comprised of event objects, event listeners, and event sources. These objects interoperate in a standard way, using method invocation to facilitate firing and handling events. The event listener registers itself with the event source to receive event notifications. At some point the event source fires an event with the event object as a parameter, and the event listener handles the event.
[1]
Interface: Using interface, you can specify a set of methods that can be implemented by one or more classes. In its traditional form, the interface, itself, does not actually define any implementation.