What is JavaBean

explanation One:The simplest understanding of JavaBean is the packet. This packet contains some information (attributes), such as name, gender, age, and so on. Contains methods that can assign values and values to these properties (get and Set methods). By instantiating the assignment operation (set method), You can take the instance out of it somewhere else and then get the value out by getting it. This is JavaBean. or VO. If there is some logic in the method. For example, when GetName, add the company name to the front of the name. Typically, It's called bo. Table-corresponding persistence class, usually called Po. or Pojo. These things can be collectively referred to as JavaBean. The core is the assignment (set) and the value (get). If you need to use the cache of read-write hard disk, network transmission is required. You need to serialize the JavaBean. Implementing the Serializable interface


EXPLANATION Two: The Java language lacks attributes, events, and multiple inheritance functions. So, if you want to implement some of the common requirements of object-oriented programming in Java programs, you can only write a lot of glue code. Java beans are the idiomatic pattern or convention for writing this set of glue code. These conventions include GetXXX, Setxxx, Isxxx, Addxxxlistener, Xxxevent, and so on. Classes that follow these conventions can be used in several tools or libraries.

For example, if someone wants to implement a one-way linked list class in Java, this might be the case:

// 编译成 java-int-list_1.0.jarpublic final class JavaIntList { static class Node { public Node next; public int value; } public Node head; public int size;}

In order to be able to quickly get the size of the list, the list size is cached in a size variable. Use the following:

JavaIntList myList = new JavaIntList();System.out.println(myList.size);

Javaintlist's author is very satisfied, so the open source of the Java-int-list Library version 1.0. The file name is Java-int-list_1.0.jar. After publishing, many users were attracted to use Java-int-list_1.0.jar.
One day, the author decides to save memory, do not cache the size variable, and change the code to this:

Compile into Java-int-list_2.0.jarPublicFinalClassJavaintlist{StaticFinalClassNode{PublicNodeNext;PublicIntValue;}PublicNodeheadpublic int getsize () {node n = headint i = 0while  (n != null ) {n = n. Nexti++; } return i}             /span>                

Then released the 2.0 version: Java-int-list_2.0.jar. After the release, the original Java-int-list_1.0.jar users have upgraded the version to 2.0. As soon as these users upgraded, they found that their programs were all broken, saying they could not find any size variables. So these users put the author to beat a meal, no longer dare to use the Java-int-list library.

The story tells us that if you don't want to be beaten to death, you have to stay backwards compatible. The Sun company also knows this truth when designing the Java language. Therefore, in the Java standard library, there will never be a public int size code, and must be written in the beginning:

private int size;public int getSize() { return size; }

Let the user start with GetSize, so that when the GetSize implementation is modified one day, it does not break backwards compatibility. This public int getsize () {return size;} Is the Java Bean.

Now it's 2014, C #, Scala, and more than Java's new object-oriented language itself provides the language features to implement these common needs, so there is no need for Java beans such a cumbersome convention.

For example, if you have a Scala version of Scalaintlist:

//compiled into Scala-int-list_1.0.jarobject scalaintlist {final case class node  (next: node Value: int }final class scalaintlist {var head< Span class= "K" >: scalaintlist.node = null var span class= "n" >size: int = 0}   

Users use this:

val myList = new ScalaIntListprintln(myList.size)

One day you change your whim to this:

Compile into Scala-int-list_2.0.jarObjectScalaintlist{FinalCaseClassNode(Next:Node,Value:Int)}FinalClassScalaintlist{Varhead: scalaintlist.node = null Span class= "K" >final def size: int = {var n = head Span class= "K" >var i = 0 while  ( span class= "n" >n != null) {n = n. Next i++  i }}   

Users will still be able to use it, without destroying backwards compatibility at all. So the Scala program does not need a convention like Java beans as long as it does not consider interacting with Java.

By the way, backwards compatibility is divided into source and binary levels, and Scala's Var or val changes to final Def, regardless of source-level backwards compatibility or binary-level backwards compatibility. However, if the field of C # is changed to a property, it does not break backward compatibility at the source level, but it can break backwards compatibility at the binary level.  This is a design flaw in C # that causes Microsoft's coding specifications to prohibit the use of public fields. Tiansheng
Links: http://www.zhihu.com/question/19773379/answer/31625054
Source: Know
Copyright belongs to the author. Commercial reprint please contact the author for authorization, non-commercial reprint please specify the source.

What is JavaBean