title: What is the disadvantages of Java Bean Class?
body: <p>I read these 2 statement mentioned below from the book <strong>Effective Java</strong></p>
  
  <p><strong>1st</strong></p>
  
  <blockquote>
    <p>Unfortunately, the JavaBeans pattern has serious disadvantages of its
    own. Because construction is split across multiple calls, a JavaBean
    may be in an inconsistent state partway through its construction.The
    class does not have the option of enforcing consistency merely by
    checking the validity of the constructor parameters. Attempting to use
    an object when it’s in an inconsistent state may cause failures that
    are far removed from the code containing the bug, hence difficult to
    debug. </p>
  </blockquote>
  
  <p><strong>2nd</strong></p>
  
  <blockquote>
    <p>A related disadvantage is that the JavaBeans pattern precludes the
    possibility of making a class immutable (Item 15), and requires added
    effort on the part of the programmer to ensure thread safety. It is
    possible to reduce these disadvantages by manually “freezing” the
    object when its construction is complete and not allowing it to be
    used until frozen, but this variant is unwieldy and rarely used in
    practice. Moreover, it can cause errors at runtime, as the compiler
    cannot ensure that the programmer calls the freeze method on an object
    before using it.</p>
  </blockquote>
  
  <p>,and I am not able to understand what exactly these 2 statement wants to convey , Can you guys help me out to understand the above statement .</p>
  
  <p><strong>Update</strong> </p>
  
  <p>I have read answers(not all) on this post , most of community members suggested me to use <code>Constructor Pattern</code> but in the same book these lines have said</p>
  
  <blockquote>
    <p>Static factories and constructors share a limitation: they do not
    scale well to large numbers of optional parameters. Consider the case
    of a class representing the Nutrition Facts label that appears on
    packaged foods. These labels have a few required fields—serving size,
    servings per container, and calories per serving— and over twenty
    optional fields—total fat, saturated fat, trans fat, cholesterol,
    sodium, and so on. Most products have nonzero values for only a few of
    these optional fields.</p>
  </blockquote>
  
  <p>For this Scenario we use <a href="http://www.captaindebug.com/2011/05/telescoping-constructor-antipattern.html" rel="noreferrer">telescoping constructor</a> pattern but </p>
  
  <blockquote>
    <p>The telescoping constructor pattern works, but it is hard to write
    client code when there are many parameters, and harder still to read
    it.The reader is left wondering what all those values mean and must
    carefully count parameters to find out. Long sequences of identically
    typed parameters can cause subtle bugs. If the client accidentally
    reverses two such parameters, the compiler won’t complain, but the
    program will misbehave at runtime</p>
  </blockquote>
  
  <p>that is why suugested to use <code>JavaBeans</code> over <code>constructor pattern</code></p>