The base-class constructor is called. This step is repeated recursively such that the root of the hierarchy is constructed first, followed by the next-derived class, etc., until the most-derived class is reached.)

    2.如果有包含关系(composition),那么它的成员对象按照声明的顺序被构造.

Member initializers are called in the order of declaration.

    3.派生类构造函数的内容(body)被执行.

The body of the derived-class constructor is called.

    一个实例:

输出:

Meal()
Lunch()
Cake()
PortableLunch()
Bread()
Cheese()
Lettuce()
Sandwich()

   main()函数中要构造一个Sandwich的对象,调用(并不是执行)它基类PortableLunch的构造函数,PortableLunch又递 归的调用,然后是Meal,Meal是继承的最底层的基类(不算Object)所以它的构造函数首先被执行,然后按次序返回到Lunch, PortableLunch,但在PortableLunch的构造函数被执行之前,它的成员对象Cake a先按照声明的顺序被构造.然后执行PortableLunch(),接着是Sandwich的成员对象,最后是Sandwich().

注:被注释掉的代码,将base-class的对象作为derive-class的成员对象,这样会递归无法结束,最后程序因堆栈耗尽而结束(Exception in  thread main java.lang.StackOverflowError).

Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1134115(转)

This Tutorial will explain you, what struts is, how it builds itself up and why it is advantage to use it for your web application. First, I will provide you some informations about Java Servlets, Java Server Pages and Java Beans, because they are parts of struts.

Java Servlets

Servlets represents java programs that runs on a web server. They allow the developer to produce dynamic web sites with java.

A Servlet has the following tasks

• It reads and processed data, which a user typed in a HTML form on a web page.

• If necessary other informations will be processed. For Example what browser or system will be used.

• It generate results with the existing data. It calls the business logic directly in the servlet or another class, which contain the logic or executes a database query.

• The results will be formated. If the browser. If the Browser expects an answer in the HTML format, then the results must be formatted in accordance with the standard. It is possible to return different formats of data with a servlet. (gif, jpeg, doc, etc.).

• Suitable answer parameters are set. Befor the servlet return the data to the browser, it sends some parameter. The parameter contains the format, that will returned by the servlet, what time the browser use to cache the site and some more.

• Return the document, in the format that it sends befor, to the browser.

Java Server Pages (JSP)

JavaServer Pages (JSP) are text documents, which are similar to HTML Files. But you find also java code in the JSP File. JavaServer Pages allow you to mix regulare, static HTML with dynamic generated contents of servlets. The java code is inserted in the HTML document on a JSP File, differently to a servlet, where the HTML code is embedded in the java code.

Java Beans are nothing else as classes, which keep a fixed naming convention, defined by Sun, for their event processing and methods. The attributes (variables) of the java beans are private. The access to these attributes is managed by access methods. The java specification specify these access methodes (getter and setter methods). If a java bean contains a attribute name, you can set or get the value of the attributes with the methode setName() or getName().

Business logic

The business logic is the core of the application. The processes are implemented in the business logic to manage the data. For Example: when someone borrows a book in a library, that is a process in the business logic. The process change the state of the data (is the book borrowsed or not) or reads the state and then provide this information for a dialog.

This short outline should be sufficient, in order to understand the structure of struts.

Sepration of dialogs and business logic (functionality)

Some peoples develop web applications with Perl or PHP and implement their SQL Querys and the business logics directly in the HTML document.

The source code looks like the following example:

You can develop in this way, when you use java servlets or JSP. It is convenient in small projects. But imagine you have 70 dialogs, many database querys in this dialogs and you want to define a field status, setting if a book is deleted or not.

Good luck

In order to alter functions and database querys easily, we should seperate these from the dialogs.

• Changes on the functionality, without working in the dialogs.

• Better overview, functionality not mixed with the dialogs.

• Easy maintain a application

• Different dialogs, but the same functionality

Central control

In order to control the interaction between the dialogs and business processes, you need a central control unit. This control unit manage all importants courses of the application, when which business process and which dialog will be used.

You have some disadvantages, if you implement the order of the processes directly to the business logic.

1. You can not reuse a part of the processes. In the following picture the process "Give Money" will bring you to the process "Select sort of icecream" every time.

2. If you want to change the order of the processes or add more options, you have to change it directly in the business logic.

Advantages of the central control

• It is easy to change the order of the business processes.

• Better overview, which dialogs will be used on which business processes.

• A central place to control the interaction between business processes and dialogs.

Translation into the technical language

The name of this model is Model-View-Controller (MVC)

Model (business logic / business processes ? Java Beans)

View (dialogs ? JavaServer Pages)

Controller (central control unit - Java Servlets)

You will find more about the MVC later in this tutorial.

More helpfully capabilities

Internationalisation

If you do not want to translate a dialog, you put the dialog texts directly into the JSP File.

Struts call the locale specific resource file by using the browser settings. You may overwrite this setting. It is quite easy to build an internationalized application with struts.

Error handling

Struts saves error messages in the business logic and can display this in the dialogs. You can show all errors or bind an error to a field (ex. Emailaddress incorrect) and show the error beside of it.

The error messages will be added to the resource files, so the errors can be internationalised too.

Validation of input fields

Whether an input field of a form contains a valid date, an email, a number or something else, in each application you have to check it. Struts supports a complete solution to validate form fields. You only have to define which form field will be checked and which error message will be displayed.

JavaServer Pages (JSP) take over the role of dialogs in struts,

Java Beans take over the business logic and business processes and

Java Servlets take over the central control unit

Thats why we talk about three great parts of struts.

Model (business logic / business processes ? Java Beans)

View (dialogs ? JavaServer Pages)

Controller (central control unit - Java Servlets)

The model represent the actual state of the application. Two kinds of java beans are used. There are java beans which contains the data of a form or data to display (ex. The books of a library) and java beans which includes the functionality of the application or call the business logic (when a user borrows a book).

The view component is responsible for the presentation of the data. The java server pages contain HTML, XML and Java Script, like a normal HTML site. Futhermore you can use java code. Struts provide tag libraries, a summary of functions, which can be use to prepare the data for displaying.

The last component is the controller. The controller manage the request of the web browser, which a user called by an address (URL). But also forward to an action which are execute and which dialogs will be used to display the informations.

The picture below illustrates the interaction between these components.

If the user sends a query with a browser, the controller(servlet) gets and processes this query. It decides which action will be called or to which view component it must be forward.

After the controller calls an action, the action can read data from a database and provide this data to the model component, java beans. The action (business logic) returns the "next step" to the controller. The controller checks what kind is the next step. (JSP View, next action, ...) and forwards to it.

The view component (JSP) reads the updated data from the model component and prepare this for the presentation. Then it sends the answer as HTML site back to the browser. The user sees the result of his query.

Struts will be configured with various configuration files. The following files are very important.

web.xml

struts-config.xml

Struts-Tag-Bibliotheken

Properties-Dateien

The illustration will show you, on which places struts use the configuration files.

web.xml

With the web.xml you configure the web server for the struts application. In this file you can set where the web server find the struts-config.xml and some other global properties.

struts-config.xml

The controller calls the business logic or a view with a name. The allocation of the names to the action classes or JSP Files(Views) will be set in the struts-config.xml. The advantage is that you can change the definition of the Workflows (Action Mapping), without using the long class names everytime. If you change a class name, you only have to change the name in the struts-config.xml. You don´t update any other part of your application.

Struts-Tag-Libraries

The Struts-Tag-Libraries, a summary of functions, extends the functionality of JavaServer pages. They support the internationalisation (multi-language) of your web application, and the easy creation of form elements.

Properties files

This files will be used to keep the internationalized textes of your web application. You can create a seperated properties file for each language, which contain all textes of the application.

转自：http://www.laliluna.de

瞬时态
由new命令开辟内存空间的java对象,

如果没有变量对该对象进行引用,它将被java虚拟机回收.

瞬时对象在内存孤立存在,它是携带信息的载体,不和数据库的数据有任何关联关系,在Hibernate中,可通过session的save()或saveOrUpdate()方法将瞬时对象与数据库相关联,并将数据对应的插入数据库中,此时该瞬时对象转变成持久化对象.

持久态
处于该状态的对象在数据库中具有对应的记录,并拥有一个持久化标识.如果是用hibernate的delete()方法,对应的持久对象就变成瞬时对象,因数据库中的对应数据已被删除,该对象不再与数据库的记录关联.

当一个session执行close()或clear()、evict()之后,持久对象变成脱管对象,此时持久对象会变成脱管对象,此时该对象虽然具有数据库识别值,但它已不在HIbernate持久层的管理之下.

持久对象具有如下特点:

1.和session实例关联;

2.在数据库中有与之关联的记录.

脱管态
当与某持久对象关联的session被关闭后,该持久对象转变为脱管对象.当脱管对象被重新关联到session上时,并再次转变成持久对象.

脱管对象拥有数据库的识别值,可通过update()、saveOrUpdate()等方法,转变成持久对象.

脱管对象具有如下特点:

1.本质上与瞬时对象相同,在没有任何变量引用它时,JVM会在适当的时候将它回收;

2.比瞬时对象多了一个数据库记录标识值.

《转》

This time I based the DAO example on interfaces. Tools like Hibernate already provide database portability, so persistence layer portability shouldn't be a driving motivation for interfaces. However, DAO interfaces make sense in more complex applications, when several persistence services are encapsulate in one persistence layer. I'd say that you should use Hibernate (or Java Persistence APIs) directly in most cases, the best reason to use an additional DAO layer is higher abstraction (e.g. methods like getMaximumBid() instead of session.createQuery(...) repeated a dozen times).

The DAO interfaces

I use one interface per persistent entity, with a super interface for common CRUDfunctionality:

The DAO interface for a particular entity extends the generic interface and provides the type arguments:

We basically separate generic CRUD operations and actual business-related data access operations from each other. (Ignore the named query constants for now, they are convenient if you use annotations.) However, even if only CRUD operations are needed for a particular entity, you should still write an interface for it, even it it is going to be empty. It is important to use a concrete DAO in your controller code, otherwise you will face some refactoring once you have to introduce specific data access operations for this entity.

An implementation with Hibernate

An implementation of the interfaces could be done with any state-management capable persistence service. First, the generic CRUD implementation with Hibernate:

public abstract class GenericHibernateDAO<T, ID extends Serializable>
        implements GenericDAO<T, ID> {

    private Class<T> persistentClass;
    private Session session;

    public GenericHibernateDAO() {
        this.persistentClass = (Class<T>) ((ParameterizedType) getClass()
                                .getGenericSuperclass()).getActualTypeArguments()[0];
     }

    @SuppressWarnings("unchecked")
    public void setSession(Session s) {
        this.session = s;
    }

    protected Session getSession() {
        if (session == null)
            throw new IllegalStateException("Session has not been set on DAO before usage");
        return session;
    }

    public Class<T> getPersistentClass() {
        return persistentClass;
    }

    @SuppressWarnings("unchecked")
    public T findById(ID id, boolean lock) {
        T entity;
        if (lock)
            entity = (T) getSession().load(getPersistentClass(), id, LockMode.UPGRADE);
        else
            entity = (T) getSession().load(getPersistentClass(), id);

        return entity;
    }

    @SuppressWarnings("unchecked")
    public List<T> findAll() {
        return findByCriteria();
    }

    @SuppressWarnings("unchecked")
    public List<T> findByExample(T exampleInstance, String[] excludeProperty) {
        Criteria crit = getSession().createCriteria(getPersistentClass());
        Example example =  Example.create(exampleInstance);
        for (String exclude : excludeProperty) {
            example.excludeProperty(exclude);
        }
        crit.add(example);
        return crit.list();
    }

    @SuppressWarnings("unchecked")
    public T makePersistent(T entity) {
        getSession().saveOrUpdate(entity);
        return entity;
    }

    public void makeTransient(T entity) {
        getSession().delete(entity);
    }

    public void flush() {
        getSession().flush();
    }

    public void clear() {
        getSession().clear();
    }

    /**
     * Use this inside subclasses as a convenience method.
     */
    @SuppressWarnings("unchecked")
    protected List<T> findByCriteria(Criterion criterion) {
        Criteria crit = getSession().createCriteria(getPersistentClass());
        for (Criterion c : criterion) {
            crit.add(c);
        }
        return crit.list();
   }

}

There are some interesting things in this implementation. First, it clearly needs a Session to work, provided with setter injection. You could also use constructor injection. How you set the Session and what scope this Session has is of no concern to the actual DAO implementation. A DAO should not control transactions or the Session scope.

We need to suppress a few compile-time warnings about unchecked casts, because Hibernate's interfaces are JDK 1.4 only. What follows are the implementations of the generic CRUD operations, quite straightforward. The last method is quite nice, using another JDK 5.0 feature, varargs. It helps us to build Criteria queries in concrete entity DAOs. This is an example of a concrete DAO that extends the generic DAO implementation for Hibernate:

Preparing DAOs with factories

We could bring it all together in a DAO factory, which not only sets the Session when a DAO is constructed but also contains nested classes to implement CRUD-only DAOs with no business-related operations:

Note that this factory example is suitable for persistence layers which are primarily implemented with a single persistence service, such as Hibernate or EJB 3.0 persistence. If you have to mix persistence APIs, for example, Hibernate and plain JDBC, the pattern changes slightly. Keep in mind that you can also call session.connection() inside a Hibernate-specific DAO, or use one of the many bulk operation/SQL support options in Hibernate 3.1 to avoid plain JDBC.

Finally, this is how data access now looks like in controller/command handler code (pick whatever transaction demarcation strategy you like, the DAO code doesn't change):

出自：http://www.hibernate.org