Overriding an internal abstract method in another

问题:

Im currently working on a c# project that uses another .net library. This library does (amongst other things) parse a sequence into a tree. All items are of some type that inherits from the abstract class Sequence. I needed to alter the behaviour slightly and subclassed Sequence myself (lets call it MySequence). After the tree was created, I could replace some tree nodes with objects of my own class.

Now, a new version of the library was published, and a Copy function with the following signature was introduced:

internal abstract Sequence Copy();

I tried to adopt my code to the new version and override it, but whatever I am doing, I get the two errors:

MySequence does not implement inherited abstract member 'Sequence.Copy()'
and:
MySequence.Copy()': no suitable method found to override

This makes sense, since it is abstract (--> it must be overwritten) and internal (--> it can not be overwritten, due to hidden visibility from outside the assembly)

So, the problem is, I understand why this is happening, but dont know what to do against it. It is crucial for my project to subclass Sequence.

And what I also dont understand is, why the internal abstract modfier is allowed in the first place as it basically permits any subclassing of the whole class from outside the assembly!?

Is there any way to solve this? Via reflection or something?

Thanks in advance!

回答1:

Basically, you are out of luck without altering the library. There may be a subclass of Sequence that does implement Copy, which you can derive from in the new version. But it is likely that the Copy method is need in other parts of the library to create clones.

回答2:

This modifier means that the class can only be inherited in the assembly that defined it.

There is no way around that.

回答3:

If a library has a type with a member with the modifiers internal abstract, I conclude that the developers of that library didn't want anyone to derive their own type from that type. You cannot work around this.

You can consider whether this was done deliberately. You should ask the publishers. It might be a mistake, in which case the publishers will probably issue a fix. If it is done deliberately, you should come up with an alternative solution without deriving from that type. EDIT: Or perhaps they intended for you to derive only from derived types in the same assembly that already implement that member.