How to design Java Beans when data items change irregularly in a database

Objective

We have not only once complained that the data items in the information system are variable and cannot be designed and implemented in Java Beans. We've done more than one thing: data items have increased or decreased, and I need to modify the information systems to accommodate them. There is one trick we need to deal with this change: daily reminders of business leaders or business people to decide data items without starting the following design and development, or a "demand milestone" for a requirement, at least the design and development associated with this requirement must not begin. This paper provides a solution to this situation, and it is called "the dynamic Braking".

JavaBean Property

As a component technology, the structure system of Java Beans is mainly composed of attributes, methods and events. As in other object-oriented technologies, in beans, attributes also act as a determinant of their current state. The access and setting of a bean's properties must be done by accessing the method and setting the method.

Let's start with an example and then explain the support for attributes in the beans component technology.

public class Author{
protected string name;
protected boolean married;
protected string[] books;
public string[] getBooks(){}
public void setBooks(integer[] x){}
public void setName(string n){}
public string getName(){}
public boolean isMarried(){}
public void setMarried(boolean bl){}
......
}

This is a very simple bean, where the modifiers for the class must be public and the Setxxx ()/getxxx () method must follow the naming rules within beans because beans determines the attributes based on the two methods. In fact, the setxxx ()/getxxx () method is the core technology of Beans's attribute mechanism.

2.1 setxxx ()/getxxx () method

The definition of a bean property depends entirely on whether there is a accessor method: the Setxxx () and the Picker (GetXXX ()), and it has nothing to do with the display in the class definition field, that is, the deletion of those protected decorated fields in the previous example has no effect on the bean. Because the internal beans is based on the access method to determine the existence of the property or not. To enable beans to confirm a property, its setup (Setxxx ()) and the Picker (GETXXX ()) must follow the following naming conventions:

An attribute name must begin with an uppercase letter in the access method;

Start with a lowercase letter elsewhere.

Of course, we do not require that each attribute must have both accessors, because we do not rule out that an attribute is readable or writable. The design of each type of attribute must be followed by a design template for this property, which describes the design templates for the various types of properties.