JavaBean Learning-Practice Examples

The first knowledge JavaBean, did not feel this bird thing has what to use, must be I am too stupid

I tested it with a JSP, and here we use the application scope to do an example

<%@ page language= "java" contenttype= "text/html; Charset=utf-8 "    pageencoding=" Utf-8 "%><! DOCTYPE HTML PUBLIC "-//w3c//dtd HTML 4.01 transitional//en" "Http://www.w3.org/TR/html4/loose.dtd" >
Originally if not javabean, you need to set the student class to new, but JavaBean can directly instantiate the object, the corresponding scope is the scope of the JSP, and then the SRC package is given, you can set the value directly
<%@ page language= "java" contenttype= "text/html; Charset=utf-8 "    pageencoding=" Utf-8 "%><! DOCTYPE HTML PUBLIC "-//w3c//dtd HTML 4.01 transitional//en" "Http://www.w3.org/TR/html4/loose.dtd" >
In addition, because the application range is scoped to the entire server, it can be accessed in different browsers, and this time use get to get the value already set.
<%@ page language= "java" contenttype= "text/html; Charset=utf-8 "    pageencoding=" Utf-8 "%><! DOCTYPE HTML PUBLIC "-//w3c//dtd HTML 4.01 transitional//en" "Http://www.w3.org/TR/html4/loose.dtd" >

At the end of the deletion, just call the RemoveAttribute method with the appropriate scope, and you can test that the corresponding scope is inaccessible.

I understand the simple, reuse code, reduce duplication of code, and then not very clear, to search the Internet, to see what Daniel said in a very detailed, and turned over
The Java language lacks attributes, events, and multiple inheritance capabilities. 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, it might be written like this://compile into Java-int-list_1.0.jarpublic final class Javaintlist {static class Node {Publi    C 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. Usage is as follows: 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, change the code to this://compile into Java-int-list_2.0.jarpublic final class Javaintlist {static final class Node {    Public Node Next;  public int value;  } public Node head;    public int GetSize () {Node n = head;    int i = 0;      while (n! = null) {n = n.next;    i++;  } return i; }} and released version 2.0: 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 areThe author was beaten up and dared not use the Java-int-list library again. 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 a Scala version of scalaintlist://is compiled into Scala-int-list_1.0.jarobject scalaintlist {final case class Node (Next:node, Value:in T)}final class Scalaintlist {var head:ScalaIntList.Node = null var size:int = 0} The user uses: Val myList = new SCALAINTLISTPR Intln (mylist.size) One day you change your whim to this://compile into Scala-int-list_2.0.jarobject scalaintlist {final case class Node (Next:node, Valu  E:int)}final class Scalaintlist {var Head:ScalaIntList.Node = null Final def size:int = {var n = head var i = 0 while (n! = null) {n = n.next i++} i}} The user can still use the same, without destroying backward 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 code level and binaryLevel, Scala's Var or val changes to final Def, regardless of source-level backward compatibility, or binary-level backwards compatibility, are not compromised. 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.

After all, that's what happened.



 
Copyright NOTICE: Reprint Please specify the source
 
JavaBean Learning-Practice Examples