如:
public class Class1
{
public Class1()
{
dosth();
}
public Class1(string s) : this()
{
dosthwith(s);
}
protected void dosth()
{
}
protected void dosthwith(string s)
{}
}
public class SubClass1 : Class1
{
public SubClass1()
{
}
}
public class TestClass
{
public TestClass()
{
//new SubClass1("test").dosth();//不能这样调用
new Class1("teswt").dosth();//可以调用
}
}
14 个解决方案
#1
up
#2
public SubClass1():base()
{
}
{
}
#3
Sample code as follows:
public TestClass()
{
base.dosth();
}
public TestClass()
{
base.dosth();
}
#4
不过基类的构造函数系统会帮你调用,所以不用显式调用。
#5
可能误会我的意思了。
我的意思是:为什么不能从父类继承它的构造函数?即 不能 new SubClass1("test") 这样去实例化?而非得在子类里再次写个同样的构造函数?
我的意思是:为什么不能从父类继承它的构造函数?即 不能 new SubClass1("test") 这样去实例化?而非得在子类里再次写个同样的构造函数?
#6
构造器只针对于当前类
#7
呵呵,恐怕只有MS知道吧
#8
呵呵,恐怕只有MS知道吧,规则是他们制定的呀
#9
public class SubClass1 : Class1
{
public SubClass1()
{
}
public SubClass1( string s ):base(s)
{
}
}
{
public SubClass1()
{
}
public SubClass1( string s ):base(s)
{
}
}
#10
这是一个复杂的问题:
.net怎么知道你是否希望子类也可以使用父类的这种构造器,而且子类无需进行更多的干预。因为,事实是,很多时候,子类并不希望暴露父类的某些构造器,或者即便暴露,也希望对其进行某种干预。因此,有必要提供一种机制,让用户决定是否以及如何暴露父类的构造器。这主要不外乎两种方式:1)默认暴露,通过额外设置可以屏蔽或者干预,2)默认不暴露,通过通过额外设置可以暴露并且干预。
二者基本上都会有一定的代价。考虑到C++以及其他00语言的惯例,我想微软的选择是不言而喻的。
.net怎么知道你是否希望子类也可以使用父类的这种构造器,而且子类无需进行更多的干预。因为,事实是,很多时候,子类并不希望暴露父类的某些构造器,或者即便暴露,也希望对其进行某种干预。因此,有必要提供一种机制,让用户决定是否以及如何暴露父类的构造器。这主要不外乎两种方式:1)默认暴露,通过额外设置可以屏蔽或者干预,2)默认不暴露,通过通过额外设置可以暴露并且干预。
二者基本上都会有一定的代价。考虑到C++以及其他00语言的惯例,我想微软的选择是不言而喻的。
#11
……
#12
up
#13
public TestClass()
{
//new SubClass1("test").dosth();//不能这样调用
new Class1("teswt").dosth();//可以调用
}
如果你定义了public SubClass1(string s)
就可以
{
//new SubClass1("test").dosth();//不能这样调用
new Class1("teswt").dosth();//可以调用
}
如果你定义了public SubClass1(string s)
就可以
#14
base.dosth();
#1
up
#2
public SubClass1():base()
{
}
{
}
#3
Sample code as follows:
public TestClass()
{
base.dosth();
}
public TestClass()
{
base.dosth();
}
#4
不过基类的构造函数系统会帮你调用,所以不用显式调用。
#5
可能误会我的意思了。
我的意思是:为什么不能从父类继承它的构造函数?即 不能 new SubClass1("test") 这样去实例化?而非得在子类里再次写个同样的构造函数?
我的意思是:为什么不能从父类继承它的构造函数?即 不能 new SubClass1("test") 这样去实例化?而非得在子类里再次写个同样的构造函数?
#6
构造器只针对于当前类
#7
呵呵,恐怕只有MS知道吧
#8
呵呵,恐怕只有MS知道吧,规则是他们制定的呀
#9
public class SubClass1 : Class1
{
public SubClass1()
{
}
public SubClass1( string s ):base(s)
{
}
}
{
public SubClass1()
{
}
public SubClass1( string s ):base(s)
{
}
}
#10
这是一个复杂的问题:
.net怎么知道你是否希望子类也可以使用父类的这种构造器,而且子类无需进行更多的干预。因为,事实是,很多时候,子类并不希望暴露父类的某些构造器,或者即便暴露,也希望对其进行某种干预。因此,有必要提供一种机制,让用户决定是否以及如何暴露父类的构造器。这主要不外乎两种方式:1)默认暴露,通过额外设置可以屏蔽或者干预,2)默认不暴露,通过通过额外设置可以暴露并且干预。
二者基本上都会有一定的代价。考虑到C++以及其他00语言的惯例,我想微软的选择是不言而喻的。
.net怎么知道你是否希望子类也可以使用父类的这种构造器,而且子类无需进行更多的干预。因为,事实是,很多时候,子类并不希望暴露父类的某些构造器,或者即便暴露,也希望对其进行某种干预。因此,有必要提供一种机制,让用户决定是否以及如何暴露父类的构造器。这主要不外乎两种方式:1)默认暴露,通过额外设置可以屏蔽或者干预,2)默认不暴露,通过通过额外设置可以暴露并且干预。
二者基本上都会有一定的代价。考虑到C++以及其他00语言的惯例,我想微软的选择是不言而喻的。
#11
……
#12
up
#13
public TestClass()
{
//new SubClass1("test").dosth();//不能这样调用
new Class1("teswt").dosth();//可以调用
}
如果你定义了public SubClass1(string s)
就可以
{
//new SubClass1("test").dosth();//不能这样调用
new Class1("teswt").dosth();//可以调用
}
如果你定义了public SubClass1(string s)
就可以
#14
base.dosth();