给一个在用Serializable接口时要注意的问题: 引用自api Serialization It is important to note that only AWT listeners which conform to the Serializable protocol will be saved when the object is stored. If an AWT object has listeners that aren't ed serializable, they will be dropped at writeObject time. Developers will need, as always, to consider the implications of making an object serializable. One situation to watch out for is this: import java.awt.*; import java.awt.event.*; import java.io.Serializable;
class MyApp implements ActionListener, Serializable { BigObjectThatShouldNotBeSerializedWithAButton bigOne; Button aButton = new Button();
MyApp() { // Oops, now aButton has a listener with a reference // to bigOne! aButton.addActionListener(this); }
public void actionPerformed(ActionEvent e) { System.out.println("Hello There"); } } In this example, serializing aButton by itself will cause MyApp and everything it refers to to be serialized as well. The problem is that the listener is serializable by coincidence, not by design. To separate the decisions about MyApp and the ActionListener being serializable one can use a nested class, as in the following example: import java.awt.*; import java.awt.event.*; import java.io.Serializable; class MyApp java.io.Serializable { BigObjectThatShouldNotBeSerializedWithAButton bigOne; Button aButton = new Button(); class MyActionListener implements ActionListener { public void actionPerformed(ActionEvent e) { System.out.println("Hello There"); } }
我的感觉:
JAVA里对象传的是引用;而不是对象的副本
所以在远程调用的时候会出问题(在C端的内存里找不倒S端的里对象的引用)
还有就是在BEAN里用的比较多点(需要象VB一样把组件的属性保存下来)
建议你多看看书
书是最好的老师
引用自api
Serialization
It is important to note that only AWT listeners which conform to the Serializable protocol will be saved when the object is stored. If an AWT object has listeners that aren't ed serializable, they will be dropped at writeObject time. Developers will need, as always, to consider the implications of making an object serializable. One situation to watch out for is this:
import java.awt.*;
import java.awt.event.*;
import java.io.Serializable;
class MyApp implements ActionListener, Serializable
{
BigObjectThatShouldNotBeSerializedWithAButton bigOne;
Button aButton = new Button();
MyApp()
{
// Oops, now aButton has a listener with a reference
// to bigOne!
aButton.addActionListener(this);
}
public void actionPerformed(ActionEvent e)
{
System.out.println("Hello There");
}
}
In this example, serializing aButton by itself will cause MyApp and everything it refers to to be serialized as well. The problem is that the listener is serializable by coincidence, not by design. To separate the decisions about MyApp and the ActionListener being serializable one can use a nested class, as in the following example:
import java.awt.*;
import java.awt.event.*;
import java.io.Serializable; class MyApp java.io.Serializable
{
BigObjectThatShouldNotBeSerializedWithAButton bigOne;
Button aButton = new Button(); class MyActionListener implements ActionListener
{
public void actionPerformed(ActionEvent e)
{
System.out.println("Hello There");
}
}
MyApp()
{
aButton.addActionListener(new MyActionListener());
}
}