Multicast Event Design Patterns

Beans that support multiple event listeners are multicast event sources. The automatic JavaBeans introspection facility uses a pair of special event registration methods for Beans that broadcast to multiple event listeners:

1. one method allows interested parties to be added as listeners, and
2. the other allows listeners to be removed.

Following are the design patterns governing these event registration methods:

public void addEventListenerType (EventListenerType x);
public void removeEventListenerType (EventListenerType x);

In these design patterns, EventListenerType refers to the object type of the event listener being registered; this object is required to implement the EventListener interface and have its name end in Listener. Applying the event design patterns to an event listener of type MouseListener would yield the following method definitions:
In the next lesson, you learn about unicast event design patterns.

public void addMouseListener(MouseListener x);
public void removeMouseListener(MouseListener x);

It is easy to get confused about the relationship between information provided by BeanInfo and information that is available through Reflection. If a Bean provides explicit information about one kind of feature in a BeanInfo object, the base classes will not be examined for information about that feature and the information in the BeanInfo is definitive. For example, if you provide explicit information about your Bean's events, the Bean and its superclasses will not be examined for further information about events. Thus, your BeanInfo must provide all of the information about events. If your Bean uses four events, BeanInfo must describe all four.
You cannot describe one and assume that the others will be discovered by reflection or by looking at a base class. Likewise, if you provide BeanInfo information about some of your Bean's methods, you must provide information about all of its methods. In this respect, BeanInfo is an "all or nothing" thing. However, do not take this too far. Providing explicit information about events does not mean that you have to provide explicit information about methods or any other types of features.
This sounds complicated, but it is not if you think about how your BeanInfo object extends the SimpleBeanInfo class. If your BeanInfo object implements getMethodDescriptors(), it must provide descriptors for all the methods you want to expose. If you do not implement getMethodDescriptors(), you inherit the default implementation from SimpleBeanInfo, which returns null, which tells the caller to use reflection to find out about methods, starting with your Bean and continuing up the inheritance hierarchy.

Given:

1. class Subject {
2.   public String title;
3.
4.   public void setTitle(String title) {
5.    if (checkTitle(title)) this.title = title;
6.   }
7.   public String getTitle() {
8.    return title;
9.   }
10.  private boolean checkTitle(String newTitle) {
11.   // code that verifies proposed title change
12.  }
13. }

Which two options are true? (Choose two options.)

Options C and D are correct because the class attribute title is kept public instead of private which is one of the basic principles of encapsulation. The naming convention for the method title is correct with an appropriate getter and setter.
Option A is incorrect because the access specifier for title is public which makes it easy to be modified by outside code.
Option B is incorrect because the Subject class does not demonstrate encapsulation since its field title is not encapsulated, meaning it is not hidden. Option E is incorrect because the checkTitle method has a private access specifier.