构造器和方法的区别
摘要
要学习Java,你必须理解构造器。因为构造器可以提供许多特殊的方法,这个对于初学者经常混淆。但是,构造器和方法又有很多重要的区别。
原作者:Robert Nielsen 原站:http://www.javaworld.com/
我们说构造器是一种方法,就象讲澳大利亚的鸭嘴兽是一种哺育动物。(按:老外喜欢打比喻,我也就照着翻译)。要理解鸭嘴兽,那么先必须理解它和其他哺育动物的区别。同样地,要理解构造器,那么就要了解构造器和方法的区别。所有学习java的人,尤其是对那些要认证考试的,理解构造器是非常重要的。下面将简单介绍一下 ,最后用一个表作了些简单的总结。
功能和作用的不同
构造器是为了创建一个类的实例。这个过程也可以在创建一个对象的时候用到:Platypus p1 = new Platypus();
相反,方法的作用是为了执行java代码。
修饰符,返回值和命名的不同
构造器和方法在下面三个方便的区别:修饰符,返回值,命名。和方法一样,构造器可以有任何访问的修饰: public, protected, private或者没有修饰(通常被package 和 friendly调用). 不同于方法的是,构造器不能有以下非访问性质的修饰: abstract, final, native, static, 或者 synchronized。
返回类型也是非常重要的。方法能返回任何类型的值或者无返回值(void),构造器没有返回值,也不需要void。
最后,谈谈两者的命名。构造器使用和类相同的名字,而方法则不同。按照习惯,方法通常用小写字母开始,而构造器通常用大写字母开始。构造器通常是一个名词,因为它和类名相同;而方法通常更接近动词,因为它说明一个操作。
"this"的用法
构造器和方法使用关键字this有很大的区别。方法引用this指向正在执行方法的类的实例。静态方法不能使用this关键字,因为静态方法不属于类的实例,所以this也就没有什么东西去指向。构造器的this指向同一个类中,不同参数列表的另外一个构造器,我们看看下面的代码:
String name;
Platypus(String input) ...{
name = input;
}
Platypus() ...{
this("John/Mary Doe");
}
public static void main(String args[]) ...{
Platypus p1 = new Platypus("digger");
Platypus p2 = new Platypus();
}
}
在上面的代码中,有2个不同参数列表的构造器。第一个构造器,给类的成员name赋值,第二个构造器,调用第一个构造器,给成员变量name一个初始值 "John/Mary Doe".
在构造器中,如果要使用关键字this,那么,必须放在第一行,如果不这样,将导致一个编译错误。
"super"的用法
构造器和方法,都用关键字super指向超类,但是用的方法不一样。方法用这个关键字去执行被重载的超类中的方法。看下面的例子:
void getBirthInfo() ...{
System.out.println("born alive.");
}
}
class Platypus extends Mammal ... {
void getBirthInfo() ...{
System.out.println("hatch from eggs");
System.out.print("a mammal normally is ");
super.getBirthInfo();
}
}
在上面的例子中,使用super.getBirthInfo()去调用超类Mammal中被重载的方法。
构造器使用super去调用超类中的构造器。而且这行代码必须放在第一行,否则编译将出错。看下面的例子:
SuperClassDemo() ...{}
}
class Child extends SuperClassDemo ... {
Child() ...{
super();
}
}
在上面这个没有什么实际意义的例子中,构造器 Child()包含了 super,它的作用就是将超类中的构造器SuperClassDemo实例化,并加到 Child类中。
编译器自动加入代码
编译器自动加入代码到构造器,对于这个,java程序员新手可能比较混淆。当我们写一个没有构造器的类,编译的时候,编译器会自动加上一个不带参数的构造器,例如:public class Example {}
编译后将如下代码:
Example() ...{}
}
在构造器的第一行,没有使用super,那么编译器也会自动加上,例如:
TestConstructors() ...{}
}
编译器会加上代码,如下:
TestConstructors() ...{
super;
}
}
仔细想一下,就知道下面的代码
public class Example {}
经过会被编译器加代码形如:
Example() {
super;
}
}
继承
构造器是不能被继承的。子类可以继承超类的任何方法。看看下面的代码:
public void sayHi {
system.out.println("Hi");
}
Example() {}
}
public class SubClass extends Example {
}
类 SubClass 自动继承了父类中的sayHi方法,但是,父类中的构造器 Example()却不能被继承。
C#
构造器
构造器负责类中成员变量(域)的初始化。C#的类有两种构造器:实例构造器和静态构造器。实例构造器负责初始化类中的实例变量,它只有在用户用new关键字为对象分配内存时才被调用。而且作为引用类型的类,其实例化后的对象必然是分配在托管堆(Managed Heap)上。这里的托管的意思是指该内存受.NET的CLR运行时管理。和C++不同的是,C#中的对象不可以分配在栈中,用户只声明对象是不会产生构造器调用的。
实例构造器分为缺省构造器和非缺省构造器。缺省构造器是在一个类没有声明任何构造器的情况下,编译器强制为该类添加的一个无参数的构造器,该构造器仅仅调用父类的无参数构造器。缺省构造器实际上是C#编译器为保证每一个类都有至少一个构造器而采取的附加规则。注意这里的三个要点:
子类没有声明任何构造器;
编译器为子类加的缺省构造器一定为无参数的构造器;
父类一定要存在一个无参数的构造器。
看下面例子的输出:
public class MyClass1
{ public MyClass1()
{
Console.WriteLine(“MyClass1 Parameterless Contructor!”);
}
public MyClass1(string param1)
{
Console.WriteLine(“MyClass1 Constructor Parameters : ”+param1); }
}
public class MyClass2:MyClass1 {}
public class Test
{
public static void Main()
{
MyClass2 myobject1=new MyClass2();
}
}
编译程序并运行可以得到下面的输出:
MyClass1 Parameterless Contructor!
读者可以去掉MyClass1的无参构造器public MyClass1()看看编译结果。
构造器在继承时需要特别的注意,为了保证父类成员变量的正确初始化,子类的任何构造器默认的都必须调用父类的某一构造器,具体调用哪个构造器要看构造器的初始化参数列表。如果没有初始化参数列表,那么子类的该构造器就调用父类的无参数构造器;如果有初始化参数列表,那么子类的该构造器就调用父类对应的参数构造器。看下面例子的输出:
public class MyClass1
{
public MyClass1()
{
Console.WriteLine("MyClass1 Parameterless Contructor!");
}
public MyClass1(string param1)
{
Console.WriteLine("MyClass1 Constructor Parameters : "+param1); }
}
public class MyClass2:MyClass1
{
public MyClass2(string param1):base(param1)
{
Console.WriteLine("MyClass2 Constructor Parameters : "+param1);
}
}
public class Test
{
public static void Main()
{
MyClass2 myobject1=new MyClass2("Hello");
}
}
编译程序并运行可以得到下面的输出:
MyClass1 Constructor Parameters : Hello
MyClass2 Constructor Parameters : Hello
C#支持变量的声明初始化。类内的成员变量声明初始化被编译器转换成赋值语句强加在类的每一个构造器的内部。那么初始化语句与调用父类构造器的语句的顺序是什么呢?看下面例子的输出:
public class MyClass1
{
public MyClass1()
{ Print(); }
public virtual void Print()
{}
}
public class MyClass2: MyClass1
{ int x = 1;
int y;
public MyClass2()
{ y = -1; Print(); }
public override void Print()
{
Console.WriteLine("x = , y = ", x, y);
}
}
public class Test { static void Main()
{
MyClass2 MyObject1 = new MyClass2();
}
}
编译程序并运行可以得到下面的输出:
x = 1, y = 0
x = 1, y = -1
容易看到初始化语句在父类构造器调用之前,最后执行的才是本构造器内的语句。也就是说变量初始化的优先权是最高的。
我们看到类的构造器的声明中有public修饰符,那么当然也可以有protected/private/ internal修饰符。根据修饰符规则,我们如果将一个类的构造器修饰为private,那么我们在继承该类的时候,我们将不能对这个private的构造器进行调用,我们是否就不能对它进行继承了吗?正是这样。实际上这样的类在我们的类内的成员变量都是静态(static)时,而又不想让类的用户对它进行实例化,这时必须屏蔽编译器为我们暗中添加的构造器(编译器添加的构造器都为public),就很有必要作一个private的实例构造器了。protected/internal也有类似的用法。
类的构造器没有返回值,这一点是不言自明的。
静态构造器初始化类中的静态变量。静态构造器不象实例构造器那样在继承中被隐含调用,也不可以被用户直接调用。掌握静态构造器的要点是掌握它的执行时间。静态构造器的执行并不确定(编译器没有明确定义)。但有四个准则需要掌握:
在一个程序的执行过程中,静态构造器最多只执行一次。
静态构造器在类的静态成员初始化之后执行。或者讲编译器会将静态成员初始化语句转换成赋值语句放在静态构造器执行的最开始。
静态构造器在任何类的静态成员被引用之前执行。
静态构造器在任何类的实例变量被分配之前执行。
看下面例子的输出:
class MyClass1
{
static MyClass1()
{
Console.WriteLine("MyClass1 Static Contructor");
}
public static void Method1()
{
Console.WriteLine("MyClass1.Method1");
}
}
class MyClass2
{
static MyClass2()
{
Console.WriteLine("MyClass2 Static Contructor");
}
public static void Method1()
{
Console.WriteLine("MyClass2.Method1");
}
}
class Test
{
static void Main()
{
MyClass1.Method1();
MyClass2.Method1();
}
}
编译程序并运行可以得到下面的输出:
MyClass1 Static Contructor
MyClass1.Method1
MyClass2 Static Contructor
MyClass2.Method1
当然也可能输出:
MyClass1 Static Contructor
MyClass2 Static Contructor
MyClass1.Method1
MyClass2.Method1
值得指出的是实例构造器内可以引用实例变量,也可引用静态变量。而静态构造器内能引用静态变量。这在类与对象的语义下是很容易理解的。
实际上如果我们能够深刻地把握类的构造器的唯一目的就是保证类内的成员变量能够得到正确的初始化,我们对各种C#中形形色色的构造器便有会心的理解--它没有理由不这样!
析构器
由于.NET平台的自动垃圾收集机制,C#语言中类的析构器不再如传统C++那么必要,析构器不再承担对象成员的内存释放--自动垃圾收集机制保证内存的回收。实际上C#中已根本没有delete操作!析构器只负责回收处理那些非系统的资源,比较典型的如:打开的文件,获取的窗口句柄,数据库连接,网络连接等等需要用户自己动手释放的非内存资源。我们看下面例子的输出:
class MyClass1
{
~MyClass1()
{
Console.WriteLine("MyClass1's destructor");
}
}
class MyClass2: MyClass1
{
~MyClass2()
{
Console.WriteLine("MyClass2's destructor");
}
}
public class Test
{
public static void Main()
{
MyClass2 MyObject = new MyClass2();
MyObject = null;
GC.Collect();
GC.WaitForPendingFinalizers();
}
}
编译程序并运行可以得到下面的输出:
MyClass2's destructor
MyClass1's destructor
其中程序中最后两句是保证类的析构器得到调用。GC.Collect()是强迫通用语言运行时进行启动垃圾收集线程进行回收工作。而GC.WaitForPendingFinalizers()是挂起目前的线程等待整个终止化(Finalizaion)操作的完成。终止化(Finalizaion)操作保证类的析构器被执行,这在下面会详细说明。
析构器不会被继承,也就是说类内必须明确的声明析构器,该类才存在析构器。用户实现析构器时,编译器自动添加调用父类的析构器,这在下面的Finalize方法中会详细说明。析构器由于垃圾收集机制会被在合适的的时候自动调用,用户不能自己调用析构器。只有实例析构器,而没有静态析构器。
那么析构器是怎么被自动调用的?这在 .Net垃圾回收机制由一种称作终止化(Finalizaion)的操作来支持。.Net系统缺省的终止化操作不做任何操作,如果用户需要释放非受管资源,用户只要在析构器内实现这样的操作即可--这也是C#推荐的做法。我们看下面这段代码:
using System;class MyClass1{ ~MyClass1() { Console.WritleLine("MyClass1 Destructor"); }}
而实际上,从生成的中间代码来看我们可以发现,这些代码被转化成了下面的代码:
class MyClass1
{
protected override void Finalize()
{
try
{
Console.WritleLine("My Class1 Destructor");
}
finally
{
base.Finalize();
}
}
}
实际上C#编译器不允许用户自己重载或调用Finalize方法--编译器彻底屏蔽了父类的Finalize方法(由于C#的单根继承性质,System.Object类是所有类的祖先类,自然每个类都有Finalize方法),好像这样的方法根本不存在似的。我们看下面的代码实际上是错的:
class MyClass
{
override protected void Finalize() {}// 错误 public void MyMethod()
{
this.Finalize();// 错误
}
}
但下面的代码却是正确的:
class MyClass
{
public void Finalize()
{
Console.WriteLine("My Class Destructor");
}
}
public class Test
{
public static void Main()
{
MyClass MyObject=new MyClass(); MyObject.Finalize();
}
}
实际上这里的Finalize方法已经彻底脱离了“终止化操作”的语义,而成为C#语言的一个一般方法了。值得注意的是这也屏蔽了父类System.Object的Finalize方法,所以要格外小心!
终止化操作在.Net运行时里有很多限制,往往不被推荐实现。当对一个对象实现了终止器(Finalizer)后,运行时便会将这个对象的引用加入一个称作终止化对象引用集的队列,作为要求终止化的标志。当垃圾收集开始时,若一个对象不再被引用但它被加入了终止化对象引用集的队列,那么运行时并不立即对此对象进行垃圾收集工作,而是将此对象标志为要求终止化操作对象。待垃圾收集完成后,终止化线程便会被运行时唤醒执行终止化操作。显然这之后要从终止化对象引用集的链表中将之删去。而只有到下一次的垃圾收集时,这个对象才开始真正的垃圾收集,该对象的内存资源才被真正回收。容易看出来,终止化操作使垃圾收集进行了两次,这会给系统带来不小的额外开销。终止化是通过启用线程机制来实现的,这有一个线程安全的问题。.Net运行时不能保证终止化执行的顺序,也就是说如果对象A有一个指向对象B的引用,两个对象都有终止化操作,但对象A在终止化操作时并不一定有有效的对象A引用。.Net运行时不允许用户在程序运行中直接调用Finalize()方法。如果用户迫切需要这样的操作,可以实现IDisposable接口来提供公共的Dispose()方法。需要说明的是提供了Dispose()方法后,依然需要提供Finalize方法的操作,即实现假托的析构函数。因为Dispose()方法并不能保证被调用。所以.Net运行时不推荐对对象进行终止化操作即提供析构函数,只是在有非受管资源如数据库的连接,文件的打开等需要严格释放时,才需要这样做。
大多数时候,垃圾收集应该交由.Net运行时来控制,但有些时候,可能需要人为地控制一下垃圾回收操作。例如在操作了一次大规模的对象集合后,我们确信不再在这些对象上进行任何的操作了,那我们可以强制垃圾回收立即执行,这通过调用System.GC.Collect() 方法即可实现,但频繁的收集会显著地降低系统的性能。还有一种情况,已经将一个对象放到了终止化对象引用集的链上了,但如果我们在程序中某些地方已经做了终止化的操作,即明确调用了Dispose()方法,在那之后便可以通过调用System.GC.SupressFinalize()来将对象的引用从终止化对象引用集链上摘掉,以忽略终止化操作。终止化操作的系统负担是很重的。
在深入了解了.NET运行时的自动垃圾收集功能后,我们便会领会C#中的析构器为什么绕了这么大的弯来实现我们的编程需求,才能把内存资源和非内存资源的回收做的游刃有余--这也正是析构的本原!