C＃继承坏了吗？ [英] C# inheritance broken?
问题描述
C＃是一种令人印象深刻的语言...但它似乎有一个很大的限制
，从C ++背景来看，似乎是不可接受的。
这里问题是：
我有第三方文档课。 （这意味着我无法更改
Document类。）我想扩展这个（继承自Document）作为
MyDocument，添加新事件和特定于应用程序方法和
属性。
我认为这不能在C＃中完成。
考虑这个例子：
class MyDocument：public Document
这不起作用，因为打开现有文档的唯一方法是
使用静态方法Document.Load（string FileName），它返回一个
Document对象。似乎没有任何方法可以将
Document对象转换或转换为MyDocument对象。因此没有办法
加载一个MyDocument对象！
>从阅读该组中的很多帖子，标准答案是：
1.Wrap对象，如下：
class MyDocument
{
protected Document TheDocument;
}
但是......这意味着我必须包含操作Document对象所需的数百种方法中的每一种。这是
显然是一个继承的情况，允许基类属性和
方法自动可用，并从
派生的增强
2.在MyDocument.Load中，调用Document.Load，然后将所有
Document的成员复制到MyDocument。
但是，这是令人望而却步的，因为复制所有Document的成员是
在运行时间和开发方面都是禁止的
努力（代码行，因此，潜在的错误）。
在C ++中，我会做这样的事情：
class MyDocument：public Document
{
public static MyDocument Load（string FileName）
{
return（MyDocument ）Document.Load（FileName）;
}
}
所以我的结论是C＃继承被破坏了（在实践中） ）因为
的严格类型检查，并没有允许这样的通讯
场景。
我错过了什么吗？
当它按照设计运行时怎么能破坏？
你还假设C ++中的常见场景在C＃中很常见，
也不是一个很好的假设。
我的答案是创建一个静态工厂类，它实例化
适当的子类。这是一个非常古老的模式，早于C＃或Java，
，你可能也想在C ++中使用它。
1月26日，下午12:06，gro ... @ isaacsoft.com写道：
C＃是一种令人印象深刻的语言......但它似乎有一个很大的局限性/>
，从C ++背景来看，似乎是不可接受的。
这就是问题所在：
我有一个第三方文档类。 （这意味着我无法更改
Document类。）我想扩展这个（继承自Document）作为
MyDocument，添加新事件和特定于应用程序方法和
属性。
我认为这不能在C＃中完成。
考虑这个例子：
class MyDocument：public Document
这不起作用，因为打开现有文档的唯一方法是
使用静态方法Document.Load（string FileName），它返回一个
Document对象。似乎没有任何方法可以将
Document对象转换或转换为MyDocument对象。因此没有办法
加载一个MyDocument对象！
通过阅读该组中的大量帖子，标准答案是：1。 "包覆与QUOT;对象如下：
class MyDocument
{
protected Document TheDocument;
}但是......这意味着我必须包含操作Document对象所需的数百种方法中的每一种。/ b
和属性。这是
显然是一个继承的情况，允许基类属性和
方法自动可用，并从
派生的增强
2.在MyDocument.Load中，调用Document.Load，然后将所有
Document的成员复制到MyDocument。
但是，这是令人望而却步的，因为复制所有Document的成员是
在运行时间和开发方面都是禁止的
努力（代码行，因此，潜在的错误）。
在C ++中，我会做这样的事情：
class MyDocument：public Document
{
public static MyDocument Load（string FileName）
{
return（MyDocument ）Document.Load（FileName）;
}
}所以我的结论是C＃继承被破坏了（在实践中）因为
严格的类型检查，并没有允许这样的交流ommon
情景。
我错过了什么吗？
只是一句忠告。
在c＃的新组中发帖时，不要来用'c＃
遗产破坏'这样的陈述，只是因为你不知道你习惯的c /＃
的方式。
更好地说我可以用c ++做到这一点，但似乎无法在c＃中找到比较的
解决方案，这是我的问题等等你会发现你得到了更多的回报。
< gr **** @ isaacsoft.com写信息
news ：11 ********************* @ a75g2000cwd.googlegro ups.com ...
C＃是一种令人印象深刻的语言...但似乎有一个很大的限制
，从C ++背景来看，似乎是不可接受的。
这是'问题：
我有第三方文档课。 （这意味着我无法更改
Document类。）我想扩展这个（继承自Document）作为
MyDocument，添加新事件和特定于应用程序方法和
属性。
我认为这不能在C＃中完成。
考虑这个例子：
class MyDocument：public Document
这不起作用，因为打开现有文档的唯一方法是
使用静态方法Document.Load（string FileName），它返回一个
Document对象。似乎没有任何方法可以将
Document对象转换或转换为MyDocument对象。因此没有办法
加载一个MyDocument对象！
>>从阅读该组中的很多帖子，标准答案是：
1.Wrap对象，如下：
class MyDocument
{
protected Document TheDocument;
}
但是......这意味着我必须包含操作Document对象所需的数百种方法中的每一种。这是
显然是一个继承的情况，允许基类属性和
方法自动可用，并从
派生的增强
2.在MyDocument.Load中，调用Document.Load，然后将所有
Document的成员复制到MyDocument。
但是，这是令人望而却步的，因为复制所有Document的成员是
在运行时间和开发方面都是禁止的
努力（代码行，因此，潜在的错误）。
在C ++中，我会做这样的事情：
class MyDocument：public Document
{
public static MyDocument Load（string FileName）
{
return（MyDocument ）Document.Load（FileName）;
}
}
所以我的结论是C＃继承被破坏了（在实践中） ）因为
的严格类型检查，并且没有任何限制这么常见的
情景。
我错过了什么吗？
Andy，
感谢您的回复。我的断言是设计被打破了！
但如果有的话，我会满足于解决方案。
如果我理解你的建议，我已经尝试过了。但是......我在需要时创建一个新的MyDocument对象没有任何问题;
我的问题是从文件中加载一个MyDocument。文档中只有一个
方法可以执行此操作：
类文档
{
public static Document Load（string FileName）;
}
我当然可以写一个新的Load方法来覆盖基本方法，因为
如下：
class MyDocument：Document
{
public static MyDocument Load（string FileName）
{
返回Document.Load（FileName）;
}
}
问题是，上面的代码不能编译，因为将Document.Load返回的Document转换为MyDocument无效
。
这有意义吗？
Tony
1月26日上午11点31分，Andy < a ... @ med-associates.comwrote：
当设计运行时，如何破坏某些东西？
你还假设C ++中的常见场景在C＃中很常见，
这也不是一个很好的假设。
我的答案是创建一个静态工厂类，它实例化
正确的子类。这是一个非常古老的模式，早于C＃或Java，
，你可能也想在C ++中使用它。
1月26日，下午12:06，gro ... @ isaacsoft.com写道：
C＃是一种令人印象深刻的语言......但它似乎有一个很大的局限性/>
，从C ++背景来看，似乎是不可接受的。
这里的问题是：
我有一个第三方文档类。 （这意味着我无法更改
Document类。）我想扩展这个（继承自Document）作为
MyDocument，添加新事件和特定于应用程序方法和
属性。
我认为这不能在C＃中完成。
考虑这个例子：
class MyDocument：public Document
这不起作用，因为使用静态方法Document.Load打开现有Document的唯一方法是
（string FileName），返回一个
Document对象。似乎没有任何方法可以将
Document对象转换或转换为MyDocument对象。因此没有办法
加载一个MyDocument对象！
>通过阅读该组中的大量帖子，标准答案为：1。 "包覆与QUOT;对象如下：
class MyDocument
{
protected Document TheDocument;
}但是......这意味着我必须包含数百种方法中的每一种
和所需的属性操纵Document对象。这是
显然是一个继承的情况，允许基类属性和
方法自动可用，并从
派生的增强类。
2.在MyDocument.Load中，调用Document.Load，然后复制所有
Document'的成员到MyDocument。
但这是令人望而却步的，因为COPYING所有Document的成员在运行时方面都是禁止的，b $ b禁止运行时间，而且在开发方面
努力（代码行，因此，潜在的错误）。
在C ++中，我会这样做：
class MyDocument：public Document
{
public static MyDocument Load（string FileName）
{
return（MyDocument ）Document.Load（FileName）;
}
}所以我的结论是C＃继承被破坏了（在实践中） ）因为
的严格类型检查，并且不允许这种常见的b $ b b场景。
我错过了什么？ - 隐藏引用的文字 - 显示引用的文字 -
C# is an impressive language...but it seems to have one big limitation
that, from a C++ background, seems unacceptable.
Here''s the problem:
I have a third-party Document class. (This means I can''t change the
Document class.) I want to extend this (inherit from Document) as
MyDocument, adding new events and application-specific methods and
properties.
I submit that this can''t be done in C#.
Consider this example:
class MyDocument : public Document
This doesn''t work because the only way to open an existing Document is
using the static method Document.Load(string FileName), which returns a
Document object. There doesn''t seem to be any way to convert or cast a
Document object to a MyDocument object. There is therefore no way to
"Load" a MyDocument object!
>From reading LOTS of posts on this group, the standard answers are:
1. "Wrap" the object, as follows:
class MyDocument
{
protected Document TheDocument;
}
But...this means that I have to wrap EACH of the hundreds of methods
and properties needed to manipulate the Document object. This is
clearly a case for inheritance, to allow the base class properties and
methods to be automatically available, with enhancements from the
derived class.
2. In MyDocument.Load, call Document.Load, and then COPY all of
Document''s members to MyDocument.
BUT, this is prohibitive because COPYING all of Document''s members is
prohibitive in terms of run time, and also in terms of development
effort (lines of code, and therefore, potential bugs).
In C++, I would do something like this:
class MyDocument : public Document
{
public static MyDocument Load(string FileName)
{
return (MyDocument)Document.Load(FileName);
}
}
So my conclusion is that C# inheritance is broken (in practice) because
of its strict type-checking, and no allowance for such a common
scenario.
Did I miss something?
How can something be broken when it functions as designed?
You also assume that a common scenario in C++ would be common in C#,
which is not a very good assumption either.
My answer would be create a static factory class which instantiates the
proper subclass. That is a pretty old pattern, predating C# or Java,
and you''d probably want to use it in C++ as well.
On Jan 26, 12:06 pm, gro...@isaacsoft.com wrote:C# is an impressive language...but it seems to have one big limitation
that, from a C++ background, seems unacceptable.
Here''s the problem:
I have a third-party Document class. (This means I can''t change the
Document class.) I want to extend this (inherit from Document) as
MyDocument, adding new events and application-specific methods and
properties.
I submit that this can''t be done in C#.
Consider this example:
class MyDocument : public Document
This doesn''t work because the only way to open an existing Document is
using the static method Document.Load(string FileName), which returns a
Document object. There doesn''t seem to be any way to convert or cast a
Document object to a MyDocument object. There is therefore no way to
"Load" a MyDocument object!
From reading LOTS of posts on this group, the standard answers are:1. "Wrap" the object, as follows:class MyDocument
{
protected Document TheDocument;
}But...this means that I have to wrap EACH of the hundreds of methods
and properties needed to manipulate the Document object. This is
clearly a case for inheritance, to allow the base class properties and
methods to be automatically available, with enhancements from the
derived class.
2. In MyDocument.Load, call Document.Load, and then COPY all of
Document''s members to MyDocument.
BUT, this is prohibitive because COPYING all of Document''s members is
prohibitive in terms of run time, and also in terms of development
effort (lines of code, and therefore, potential bugs).
In C++, I would do something like this:
class MyDocument : public Document
{
public static MyDocument Load(string FileName)
{
return (MyDocument)Document.Load(FileName);
}
}So my conclusion is that C# inheritance is broken (in practice) because
of its strict type-checking, and no allowance for such a common
scenario.
Did I miss something?
Just a word of advice.
When posting on a newgroup of c#, don''t come out with statements like ''c#
inheritence broken'' just because you don''t know the c# way of doing
something you are used to.
Better to say i can do this in c++ but can''t seem to find a comparative
solution in c#, here is my problem etc etc. You''ll find you get a much
better response.
<gr****@isaacsoft.comwrote in message
news:11*********************@a75g2000cwd.googlegro ups.com...C# is an impressive language...but it seems to have one big limitation
that, from a C++ background, seems unacceptable.
Here''s the problem:
I have a third-party Document class. (This means I can''t change the
Document class.) I want to extend this (inherit from Document) as
MyDocument, adding new events and application-specific methods and
properties.
I submit that this can''t be done in C#.
Consider this example:
class MyDocument : public Document
This doesn''t work because the only way to open an existing Document is
using the static method Document.Load(string FileName), which returns a
Document object. There doesn''t seem to be any way to convert or cast a
Document object to a MyDocument object. There is therefore no way to
"Load" a MyDocument object!
>>From reading LOTS of posts on this group, the standard answers are:
1. "Wrap" the object, as follows:
class MyDocument
{
protected Document TheDocument;
}
But...this means that I have to wrap EACH of the hundreds of methods
and properties needed to manipulate the Document object. This is
clearly a case for inheritance, to allow the base class properties and
methods to be automatically available, with enhancements from the
derived class.
2. In MyDocument.Load, call Document.Load, and then COPY all of
Document''s members to MyDocument.
BUT, this is prohibitive because COPYING all of Document''s members is
prohibitive in terms of run time, and also in terms of development
effort (lines of code, and therefore, potential bugs).
In C++, I would do something like this:
class MyDocument : public Document
{
public static MyDocument Load(string FileName)
{
return (MyDocument)Document.Load(FileName);
}
}
So my conclusion is that C# inheritance is broken (in practice) because
of its strict type-checking, and no allowance for such a common
scenario.
Did I miss something?
Andy,
Thanks for your response. My assertion is that the DESIGN is broken!
But I''ll settle for a work-around, if there is one.
If I understand your suggestion, I''ve already tried this. But...I
don''t have any problem creating a new MyDocument object when I need it;
my problem is loading a MyDocument from a file. There is only one
method in Document that does this:
class Document
{
public static Document Load(string FileName);
}
I can certainly write a new Load method to override the base method, as
follows:
class MyDocument : Document
{
public static MyDocument Load(string FileName)
{
return Document.Load(FileName);
}
}
The problem is, the above code won''t compile, because it is not valid
to cast the Document returned by Document.Load to a MyDocument.
Does that make sense?
Tony
On Jan 26, 11:31 am, "Andy" <a...@med-associates.comwrote:How can something be broken when it functions as designed?
You also assume that a common scenario in C++ would be common in C#,
which is not a very good assumption either.
My answer would be create a static factory class which instantiates the
proper subclass. That is a pretty old pattern, predating C# or Java,
and you''d probably want to use it in C++ as well.
On Jan 26, 12:06 pm, gro...@isaacsoft.com wrote:
C# is an impressive language...but it seems to have one big limitation
that, from a C++ background, seems unacceptable.
Here''s the problem:
I have a third-party Document class. (This means I can''t change the
Document class.) I want to extend this (inherit from Document) as
MyDocument, adding new events and application-specific methods and
properties.
I submit that this can''t be done in C#.
Consider this example:
class MyDocument : public Document
This doesn''t work because the only way to open an existing Document is
using the static method Document.Load(string FileName), which returns a
Document object. There doesn''t seem to be any way to convert or cast a
Document object to a MyDocument object. There is therefore no way to
"Load" a MyDocument object!
>From reading LOTS of posts on this group, the standard answers are:1. "Wrap" the object, as follows:class MyDocument
{
protected Document TheDocument;
}But...this means that I have to wrap EACH of the hundreds of methods
and properties needed to manipulate the Document object. This is
clearly a case for inheritance, to allow the base class properties and
methods to be automatically available, with enhancements from the
derived class.
2. In MyDocument.Load, call Document.Load, and then COPY all of
Document''s members to MyDocument.
BUT, this is prohibitive because COPYING all of Document''s members is
prohibitive in terms of run time, and also in terms of development
effort (lines of code, and therefore, potential bugs).
In C++, I would do something like this:
class MyDocument : public Document
{
public static MyDocument Load(string FileName)
{
return (MyDocument)Document.Load(FileName);
}
}So my conclusion is that C# inheritance is broken (in practice) because
of its strict type-checking, and no allowance for such a common
scenario.
Did I miss something?- Hide quoted text -- Show quoted text -
这篇关于C＃继承坏了吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
