Reviewing the Role of Interface-based Programming
Building a reusable, modular, component-driven system encourages the use of interfaces. Simply put, an
interface is a contract between a caller and an object. Interfaces never provide implementation details, only
member definitions.
Interface-based programming is certainly not new and not exclusive to the .NET platform or WCF. DCOM is
a component-based system based entirely on interface-based programming. The .NET remoting API
encourages the use of interfaces, although they are not mandatory. Java-based systems can also be built using
strongly typed interfaces. Even non-OOP-based languages such as C can make use of interface-based
programming techniques.
The use of interfaces in any framework or language is a very elegant way to design software. Once an
interface is defined, a service may implement the abstract members in its own particular manner. This allows
for interface-based polymorphism. In code, you can make assumptions such as ‘if you support this interface,
you provide a specific functionality’. Unlike a traditional abstract base class, interfaces can be plugged in
throughout a class hierarchy, even if the types have no common parent (other than System.Object).
Consider the use of interfaces in ADO.NET. The IDbConnection interface defines a set of members that
represent the behavior of connecting to an external database. Many classes (SqlConnection,
OracleConnection, OdbcConnection, and others) implement this interface in their own unique way.
// C# (VB interface definition would be similar)
public interface IDbConnection : IDisposable
{
// Methods.
IDbTransaction BeginTransaction();
IDbTransaction BeginTransaction(IsolationLevel il);
void ChangeDatabase(string databaseName);
void Close();
IDbCommand CreateCommand();
void Open();
// Properties.
string ConnectionString { get; set; }
int ConnectionTimeout { get; }
string Database { get; }
ConnectionState State { get; }
}
Interfaces provide a robust versioning scheme for software components. Once an interface has been defined
and put into production, best practice states the interface never changes. If you were to remove or change
interface members, you might break existing software components. Adding new members to an interface will
typically will not break existing code.
In essence, changing an existing interface nullifies the ‘contract’ between the caller and the implementer. To
safely modify existing functionality of a component, you create and implement new interfaces (and leave the
existing interfaces intact). New clients will be able to make use of the new functionality. Existing clients will
be blissfully unaware of the new functionality and will not need to change their code base.
As helpful as interfaces may be from a design point of view, they can complicate the creation of distributed
systems. The first problem is that when you design an interface, you must use the type system of your
language or platform to do so. Consider again the .NET IDbConnection interface. Here are a number of
parameters/return value specific to the .NET platform (ConnectionState, System.String, System.Int32,
IsolationLevel, other interfaces, and so on).
// Bold members are .NET specific types.
public interface IDbConnection : IDisposable
{
IDbTransaction BeginTransaction();
IDbTransaction BeginTransaction(IsolationLevel il);
void ChangeDatabase(string databaseName);
void Close();
IDbCommand CreateCommand();
void Open();
string ConnectionString { get; set; }
int ConnectionTimeout { get; }
string Database { get; }
ConnectionState State { get; }
}
One benefit of .NET is its language-agnostic mindset. It is entirely possible to define an interface in one
language (C#) and implement it using another .NET language (VB, Delphi, Boo, and so on). The reason is that
all .NET languages target the Common Type System (CTS). The CTS describes the full details of the .NET
type system.
Consider the same IDbConnection interface now defined using VB. Although different .NET languages have
unique keywords and constructs, at compile time they use the same underlying type system. Furthermore,
the only ‘real’ language of .NET is CIL code. Languages such as C# or VB are simply higher-level abstractions.
' VB
Public Interface IDbConnection
Inherits IDisposable
Function BeginTransaction() As IDbTransaction
Function BeginTransaction(ByVal il As IsolationLevel) As IDbTransaction
Sub ChangeDatabase(ByVal databaseName As String)
Sub Close()
Function CreateCommand() As IDbCommand
Sub Open()
Property ConnectionString As String
ReadOnly Property ConnectionTimeout As Integer
ReadOnly Property Database As String
ReadOnly Property State As ConnectionState
End Interface
Although the .NET platform allows you to build components using a variety of programming languages, the
limitation is they all must be ‘.NET-aware’ languages. .NET particulars (ConnectionState, System.String,
System.Int32, and so on) mean nothing to systems built using another platform (JAVA EE, COM, and the
like). Communication between a Java application and a .NET IDbConnection interface requires building or
buying a ‘bridge’ (a.k.a. mapping layer).
For example, it would be possible to translate the .NET ConnectionState enum into a Java-centric equivalent.
As you might imagine, translating all exposed .NET types to a Java-based system would be very labor
intensive. Even though interface types work wonders for distributed applications that understand the same
type system, XML web services enable a higher degree of interoperability.
As you will see, when you make use of an HTTP-based binding, your .NET interfaces will be used to
generate a proper WSDL description of the functionality of a WCF service. Therefore, when programming the
service, you make use of strongly typed interfaces. However, based on your choice of binding, the caller may
not directly see them. Using this model, you gain the benefits of strong typing without the need to lock
yourself into a proprietary type system.
Building a reusable, modular, component-driven system encourages the use of interfaces. Simply put, an
interface is a contract between a caller and an object. Interfaces never provide implementation details, only
member definitions.
Interface-based programming is certainly not new and not exclusive to the .NET platform or WCF. DCOM is
a component-based system based entirely on interface-based programming. The .NET remoting API
encourages the use of interfaces, although they are not mandatory. Java-based systems can also be built using
strongly typed interfaces. Even non-OOP-based languages such as C can make use of interface-based
programming techniques.
The use of interfaces in any framework or language is a very elegant way to design software. Once an
interface is defined, a service may implement the abstract members in its own particular manner. This allows
for interface-based polymorphism. In code, you can make assumptions such as ‘if you support this interface,
you provide a specific functionality’. Unlike a traditional abstract base class, interfaces can be plugged in
throughout a class hierarchy, even if the types have no common parent (other than System.Object).
Consider the use of interfaces in ADO.NET. The IDbConnection interface defines a set of members that
represent the behavior of connecting to an external database. Many classes (SqlConnection,
OracleConnection, OdbcConnection, and others) implement this interface in their own unique way.
// C# (VB interface definition would be similar)
public interface IDbConnection : IDisposable
{
// Methods.
IDbTransaction BeginTransaction();
IDbTransaction BeginTransaction(IsolationLevel il);
void ChangeDatabase(string databaseName);
void Close();
IDbCommand CreateCommand();
void Open();
// Properties.
string ConnectionString { get; set; }
int ConnectionTimeout { get; }
string Database { get; }
ConnectionState State { get; }
}
Interfaces provide a robust versioning scheme for software components. Once an interface has been defined
and put into production, best practice states the interface never changes. If you were to remove or change
interface members, you might break existing software components. Adding new members to an interface will
typically will not break existing code.
In essence, changing an existing interface nullifies the ‘contract’ between the caller and the implementer. To
safely modify existing functionality of a component, you create and implement new interfaces (and leave the
existing interfaces intact). New clients will be able to make use of the new functionality. Existing clients will
be blissfully unaware of the new functionality and will not need to change their code base.
As helpful as interfaces may be from a design point of view, they can complicate the creation of distributed
systems. The first problem is that when you design an interface, you must use the type system of your
language or platform to do so. Consider again the .NET IDbConnection interface. Here are a number of
parameters/return value specific to the .NET platform (ConnectionState, System.String, System.Int32,
IsolationLevel, other interfaces, and so on).
// Bold members are .NET specific types.
public interface IDbConnection : IDisposable
{
IDbTransaction BeginTransaction();
IDbTransaction BeginTransaction(IsolationLevel il);
void ChangeDatabase(string databaseName);
void Close();
IDbCommand CreateCommand();
void Open();
string ConnectionString { get; set; }
int ConnectionTimeout { get; }
string Database { get; }
ConnectionState State { get; }
}
One benefit of .NET is its language-agnostic mindset. It is entirely possible to define an interface in one
language (C#) and implement it using another .NET language (VB, Delphi, Boo, and so on). The reason is that
all .NET languages target the Common Type System (CTS). The CTS describes the full details of the .NET
type system.
Consider the same IDbConnection interface now defined using VB. Although different .NET languages have
unique keywords and constructs, at compile time they use the same underlying type system. Furthermore,
the only ‘real’ language of .NET is CIL code. Languages such as C# or VB are simply higher-level abstractions.
' VB
Public Interface IDbConnection
Inherits IDisposable
Function BeginTransaction() As IDbTransaction
Function BeginTransaction(ByVal il As IsolationLevel) As IDbTransaction
Sub ChangeDatabase(ByVal databaseName As String)
Sub Close()
Function CreateCommand() As IDbCommand
Sub Open()
Property ConnectionString As String
ReadOnly Property ConnectionTimeout As Integer
ReadOnly Property Database As String
ReadOnly Property State As ConnectionState
End Interface
Although the .NET platform allows you to build components using a variety of programming languages, the
limitation is they all must be ‘.NET-aware’ languages. .NET particulars (ConnectionState, System.String,
System.Int32, and so on) mean nothing to systems built using another platform (JAVA EE, COM, and the
like). Communication between a Java application and a .NET IDbConnection interface requires building or
buying a ‘bridge’ (a.k.a. mapping layer).
For example, it would be possible to translate the .NET ConnectionState enum into a Java-centric equivalent.
As you might imagine, translating all exposed .NET types to a Java-based system would be very labor
intensive. Even though interface types work wonders for distributed applications that understand the same
type system, XML web services enable a higher degree of interoperability.
As you will see, when you make use of an HTTP-based binding, your .NET interfaces will be used to
generate a proper WSDL description of the functionality of a WCF service. Therefore, when programming the
service, you make use of strongly typed interfaces. However, based on your choice of binding, the caller may
not directly see them. Using this model, you gain the benefits of strong typing without the need to lock
yourself into a proprietary type system.
Interface-based Programming
Table of Contents
Copyright (c) 2008. Intertech, Inc. All Rights Reserved. This information is to be used exclusively as an
online learning aid. Any attempts to copy, reproduce, or use for training is strictly prohibited.
online learning aid. Any attempts to copy, reproduce, or use for training is strictly prohibited.
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
Courseware
Training Resources
Tutorials
Services