非泛型接口的约束类似于泛型或AttributeUsage

Question

EDIT: This is more of a good design question that came up while refactoring and combining reusable code into a library.

I am consolidating frequently used code from over the years to a library and interfaces play a large part here. While refactoring, one of the main categories that interfaces are split in include whether they were designed for mutable or immutable scenarios. Consider the following:

Mutable and Immutable:

interface ICloneable<T> { T Clone (); }

Immutable:

interface ISomeInterface { T SomeFunc (); }

Mutable

interface IInitializable { void Initialize (); }
interface ICopyable<T>: IInitializable { T CopyFrom (T source); T CopyTo (T destination); }

The case of IInitializable is the odd one out as there is no reason for it to accept a generic parameter. However, without one, it cannot enforce usage with classes only.

I assume that constraints do not exist for non-generic types so the question is whether there is a way to enforce this at runtime (or better at compile time)? Besides generics, attributes can also be restricted (not that it matters here).

Of course I could just make the interface generic but that wouldn't be a good enough reason would it? Any elegant way to achieve this?

Answer 1

There is no way in the C# language to prevent a struct from implementing your interface. Any type is free to implement any interface so long as it can satisfy the methods described there.

However you can constrain the usages of IInitializable to only work with implementations that are class types. For example

void M<T>(T value) where T : IInitializable, class 

This can be used to constrain your usage scenarios to class only and hence get the guarantee you are looking for

Answer 2

Your code looks like Java.

C# supports operator overloading and user-defined conversions, so your ICopyable<T> seems redundant.

Also, unless you really need a generic Clone() method, you're probably just as well-off defining copy constructors; you can always use double-dispatch internally. By 'really need', I mean, is the algorithm truly generic?

Edit: Clonable in Java was a kludge to get around the fact that it didn't support templates/generics. C# does, so your algorithm can match on type and you can use simple-to-use copy construtors.

Finally, WRT to Initialize() , if it's a generic no-argument method, why not just put the code in the constructor? It's going to be far easier for people to use and understand. If your object is only partially inialised at contruction, then you need to check and throw InvalidOperationException s anyway, so why complicate your interface?

If the Initialise() method is to support polymorphism, then it shouldn't be in an interface, as it's an implementation detail - interfaces are about how people use your objects, no how you build them; the fact that that the compiler does some checks on them is secondary to their purpose.