Interface-Based Programming - Interface Implementation
(Page 2 of 4 )
To implement an interface, all a class has to do is derive from it. Example 3-1 shows the class MyClass implementing the interfaceIMyInterface.
Example 3-1. Defining and implementing an interface
public interface IMyInterface
{
void Method1();
void Method2();
void Method3();
}
public class MyClass : IMyInterface
{
public void Method1()
{...}
public void Method2()
{...}
public void Method3()
{...}
//other class members
}
As trivial as Example 3-1 is, it does demonstrate a number of important points. First, interfaces have visibility—an interface can be private to its assembly (using theinternalaccess modifier) or it can be used from outside the assembly (with thepublicaccess modifier), as in Example 3-1. Second, even though the methods the interface defines have no access modifiers, they are by definition public, and the implementing class has to declare its interface methods as public. Third, there is no need to useneworoverrideto qualify the method redefinition in the subclass, because an interface method by its very nature can’t have any implementation and therefore has nothing to override. (If you aren’t familiar with theneworoverridekeywords, see the sidebar “C# Inheritance Directives” later in this chapter.) Finally, the class must implement all the methods the interface defines, without exception. If the class is an abstract class, it can redefine the methods without providing concrete implementation.
Example 3-2 shows how to define and implement an interface in Visual Basic 2005. In Visual Basic 2005, you need to state which interface method a class method corresponds to. As long as the signature (i.e., the parameters and return value) matches, you can even use a different name for the method. In addition, because the default accessibility in Visual Basic 2005 is public, unlike in C#, adding thePublicqualifier is optional.
Example 3-2. Defining and implementing an interface in Visual Basic 2005
Public Interface IMyInterface
Sub Method1()
Sub Method2()
Sub Method3()
End Interface
Public Class SomeClass
Implements IMyInterface
Public Sub Method1() Implements IMyInterface.Method1
...
End Sub
Public Sub Method2() Implements IMyInterface.Method2
...
End Sub
Public Sub Method3() Implements IMyInterface.Method3
...
End Sub
End Class
To interact with an object using an interface, all a client has to do is instantiate a concrete class that supports the interface and assign that object to an interface
variable, similar to using any other base type. Using the same definitions as in Example 3-1, the client code might be:
IMyInterface obj;
obj = new MyClass();
obj.Method1();
Interfaces promote loose coupling between clients and objects. When you use interfaces, there’s a level of indirection between the client’s code and the object implementing the interface. If the client wasn’t responsible for instantiating the object, there is nothing in the client code that pertains to the object hidden behind the interface shield. There can be many possible implementations of the same interface, such as:
public interface IMyInterface
{...}
public class MyClass : IMyInterface
{...}
public class MyOtherClass : IMyInterface
{...}
When a client obtains an interface reference by creating an object of typeMyClass, the client is actually saying to .NET “give meMyClass’s interpretation of the wayIMyInterfaceshould be implemented.”
Treating interfaces as binary contracts, which shields clients from changes made to the service providers, is exactly the idea behind COM interfaces, and logically, .NET interfaces have the same semantics as COM interfaces. If you are an experienced COM developer or architect, working with interfaces is probably second nature to you, and you will feel right at home with .NET interfaces.
However, unlike COM, .NET doesn’t enforce separation of the interface from the implementation. For example, using the definitions in Example 3-1, the client’s code can also be:
MyClass obj;
obj = new MyClass();
obj.Method1();
Because of the way the server in Example 3-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 all developers, including those who have trouble with the more abstract concepts of interface-based programming (see the section “.NET Adherence to Component Principles” in Chapter 1). The fact that something is possible, of course, doesn’t mean you should go ahead and do it. Disciplined .NET developers should always enforce the separation, to retain the benefits of interface-based programming.
Next: Explicit Interface Implementation >>
More .NET Articles
More By O'Reilly Media
|
 This article is excerpted from chapter three of Programming .NET Components, Second Edition, written by Juval Lowy (O'Reilly, 2006; ISBN: 0596007620). Check it out today at your favorite bookstore. Buy this book now.
|
|
