19. ***WHY*** do Java Bean classes have the development guidelines below? Please number your answers, and use BRIEF, SIMPLE, DESCRIPTIVE terms in your answer. (P.S. I don't like the term "encapsulation" much. It means to enclose - but what does THAT do?) 1. WHY are the data fields in a bean declared PRIVATE? (Application programs certainly need access to these field values!) 2. WHY is there a CONVENTION for the NAMES of the getter/setter methods? (The convention is: get/set + field name. That's NOT the question.) (There is no CONVENTION for APPLICATION programs method names. Why BEAN method names?) 3. WHY provide a toString() method? (Application programs don't provide a toString(). And besides, beans have a getter method for each field.) 4. WHY must a constructor with no args be provided in a bean class? (Applications may not have a no-arg constructor. Why beans?) 5. WHY should a bean object strive to implement the Serializable interface? (Applications don't implement Serializable. Why beans?) 6. WHAT is the keyword that can be specified on a field declaration line that signals to the writeObject() method: "Don't write out this field when the object is being externalized." 7. WHY does a bean class not have a main() method? (Almost all the application programs we wrote this semester had one! Why not beans?) 8. WHY is a thread hardly ever started in a bean constructor to run the bean? (Application programs often do this! Why not beans?) List the *REASON* for each convention above. And be ***BRIEF***! No examples. (Points *OFF* for long answers!) Read the questions carefully. Note question #2 above does not ask why beans have getter and setter methods or what the naming convention is - it asks why the NAMES of the methods follow a standardized naming CONVENTION that involves the field names. Question #3 does not ask what the toString() method does, it asks *WHY* one is needed. Question #4 - note that a call to super(); is NOT going to pass any parameters to a parent constructor!