Interfaces

Interfaces

An interface is a special kind of type, defined in Partition I of the ECMA Standard Proposal as “a named group of methods, locations and other contracts that shall be implemented by any object type that supports the interface contract of the same name.” In other words, an interface is not a “real” type but merely a named descriptor of methods and properties exposed by other types. Conceptually, an interface in the common language runtime is similar to a COM interface—or at least the general idea is the same.

Not being a real type, an interface is not derived from any other type, nor can other types be derived from an interface. But an interface can “implement” other interfaces. This is not a true implementation, of course. When we say that “interface IA implements interfaces IB and IC,” we mean only that the contracts defined by IB and IC are subcontracts of the contract defined by IA.

As a descriptor of items (methods, properties, events) exposed by other types, an interface cannot offer its own implementation of these items and thus is, by definition, an abstract type. When you define an interface in ILAsm, you can omit the keyword abstract because the compiler adds this flag automatically when it encounters the keyword interface.

For the same reason, an interface cannot have instance fields, because a declaration of a field is the field’s implementation. However, an interface can and must offer implementation of its static members—the items shared by all instances of a type—if it has any. Bear in mind, of course, that the definition of static as “shared by all instances” is general for all types and does not imply that interfaces can be instantiated. They cannot be. Interfaces are inherently abstract and cannot even have instance constructors.

Static members (fields, methods) of an interface are not part of the contract defined by the interface and have no bearing on the types that implement the interface. A type implementing an interface must implement all instance members of the interface, but it has nothing to do with the static members of the interface.

The nature of an interface as a descriptor of items exposed by other types requires that the interface itself and all its members must be public, which makes perfect sense— we are, after all, talking about exposed items.

Interfaces have several limitations. One is obvious: because an interface is not a real type, it does not have layout. It simply doesn’t make sense to talk about the packing size or total size of a contract descriptor.

Another limitation is not so obvious: interfaces should not be sealed. This might sound contradictory because, as just noted, no types can be derived from interfaces—which is precisely the definition of sealed. But a more general rule, applicable to all types, dictates that an abstract type cannot be sealed. Formally, an interface is a type, and it is inherently abstract; ergo, it cannot be marked as sealed, notwithstanding the fact that no type can be derived from it.



Inside Microsoft. NET IL Assembler
Inside Microsoft .NET IL Assembler
ISBN: 0735615470
EAN: 2147483647
Year: 2005
Pages: 147
Authors: SERGE LIDIN

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net