.NET Interface-based Programming (Cont.) Separation of Interface from Implementation Separation of interface from implementation is a core principle of component-oriented programming. When separating interface from implementation, the clients program against an abstraction of the service (the interface) not a particular implementation of it (the object). As a result, changing an implementation detail on the server (or even switching to a different service provider altogether) does not affect the clients. (The client responsible for creating the object may still end up with one line of code pertaining to the object type, but even that one line can be hidden away using class factories.) However, unlike COM, .NET does not enforce separating interface from implementation. For example, using the definitions of Listing 1, the client's code could also be: MyClass obj;
obj = new MyClass();
obj.Method1();
Meaning, because of the way the server in Listing 1 implements the interface (as public members), nothing prevents the client from programming directly against the object providing the service instead of the interface. I believe this is because .NET tries to make component-oriented programming accessible to every kind of developer, including those who have trouble with the more abstract concepts of interface-based programming. The fact that something is possible does not, of course, give permission to do it. Disciplined .NET developers should always enforce the separation to retain the benefits of interface-based programming. The following simple techniques will enable both server and client developers to provide the separation.
Explicit Interface Implementation The server implementing the interface can actually prevent accessing the interface methods directly, using explicit interface implementation. Implementing an interface explicitly means qualifying the interface members' implementation with the interface that defines them: public interface IMyInterface
{
void Method1();
void Method2();
}
public class MyClass : IMyInterface
{
void IMyInterface.Method1(){...}
void IMyInterface.Method2(){...}
//Other methods and members
}
Note that when using explicit implementation, the interface members must be defined at the class's scope as private (you cannot use any explicit visibility modifier, including private, on them). The only way clients can invoke the methods of explicitly implemented interfaces is by accessing them via the interface: IMyInterface obj;
obj = new MyClass();
obj.Method1();
Using explicit interface implementation, server-side developers can rigorously enforce the separation of interface from implementation. Defensive Client-Side Programming Never assume an object supports an interface. In most cases, you should always program defensively on the client side, using the as operator as shown in Listing 3. Doing so caters both for robust error handling and for separation of interface from implementation, regardless of whether the server uses explicit interface implementation or not. Make it a habit on the client side to use the server via an interface and thus enforce the separation manually.
Assemblies with Interfaces Only Because interfaces can be implemented by multiple parties, it is a good practice to put them in a separate assembly from that of the servers. This separate assembly contains interfaces only and is shared by both the server and the client developers. It is even possible to use class factories and have the server assemblies define only internal classes, which forces the clients to use the public interfaces. A separate interface assembly also allows for concurrent development of the server and the client (once the two parties have agreed on the interfaces). Assemblies with interfaces only extend the separation of interface from implementation further down to the code-packaging units. Interface Methods, Properties and Events An interface is not limited to defining methods only. An interface can define methods, properties, indexers and events. Listing 4 shows the syntax for defining all of those in an interface, and the corresponding implementation.
Interfaces and Structs An interesting use of interfaces with properties involves structs. In .NET, a struct cannot have a base struct or a base class because it is a value type. However, .NET does permit structs to derive from one or more interfaces. The reason for this is that sometimes you want to define abstract data storage and there are a number of possible implementations for the actual structure. By defining an interface (preferably with properties only, but it can have methods as well), you could pass around that interface, instead of the actual struct, and gain the benefits of polymorphism, even though structs are not allowed to derive from a common base struct. Listing 5 demonstrates the use of an interface (with properties only) as a base type for structs.
More on Implementing Interfaces A class could derive from as many interfaces as required (see Listing 2), but a class is limited to only one base class at the most. When deriving from a base class and from interfaces, the base must be listed first in the derivation chain, and this is enforced by the compiler: public interface IMyInterface
{}
public interface IMyOtherInterface
{}
public class MyBaseClass
{}
public class MySubClass : MyBaseClass,
IMyInterface,IMyOtherInterface
{}
Even such a trivial example raises a number of questions: what if both interfaces define identical methods? What are the ways to resolve such collusions? What if the base class already derives from one or more of the interfaces? Let's address these questions.
| & | |
Is .NET Well-Factored?
After writing down the rules of thumb and metrics for interface factoring, I was curious to see how the various interfaces defined by the .NET Framework compare. I examined more than 300 interfaces defined by .NET. I excluded from the survey the COM interoperation interfaces redefined in .NET because I wanted to look at native .NET interfaces only. I also excluded from the results the outliers?interfaces with zero members (nine of them) and interfaces with more than 20 members (eight of them). I consider an interface with more than 20 members to be a poorly factored one, not to be used as an example. On average, a .NET Framework interface has 3.75 members, with a methods to properties ratio of 3.5:1. Less than 3 percent of the members are events. These metrics nicely reaffirm the rules of thumb outlined in this article. You could say that, on average, .NET interfaces are well factored. |