|only for RuBoard|
The concept of separating the interface from the implementation has been around for some time. You have seen how code written against an abstract base class allows you to write applications that can grow over time and remain resistant to some of the more negative aspects of change. This is not a new idea. C++ programmers have been using the same technique for years. In fact, the open-closed principle (see Chapter 4) is based on this idea.
Visual Basic .NET provides a more formal declaration of this notion of separation called an interface. At the highest level, an interface contains a group of related methods to perform a task or describe a service. It is similar to an abstract base class that does not contain implementation, and it serves a similar purpose as well. It acts as a contract, describing a behavior that an object provides. Any object that implements an interface has to provide an implementation of everything included within the interface definition.
Although they have been with the language for some time now, interfaces are one of the most misunderstood features of VB.NET. Undoubtedly, interfaces will continue to be neglected in lieu of implementation inheritance. This is unfortunate because interface-based programming is as important now as it was in the past. And in terms of inheritance, it is not an either-or situation. Interfaces have their place alongside implementation inheritance. In fact, each principle and technique discussed in the last chapter is even more beneficial when used with interfaces.
Interfaces are declared in a manner similar to a class, but they contain only methods (such as Function, Sub, or Property) and events. Example 5-1 shows the definition of a simple interface.
Public Interface IPaintable Sub Paint(ByVal color As System.Drawing.Color) ReadOnly Property Color( ) As System.Drawing.Color Event Completed( ) End Interface
While the interface itself can be declared with any visibility, the individual methods and events are inherently public, so no modifier is used. In fact, the compiler complains if you try to use one.
A class describing an object that can be painted can now implement the interface, as Example 5-2 demonstrates.
Imports System Imports System.Drawing Public Class Car Implements IPaintable Private myColor As Color Public Event Painted( ) Implements IPaintable.Completed Public Sub Paint(ByVal aColor As Color) Implements IPaintable.Paint myColor = aColor RaiseEvent Painted( ) End Sub Public ReadOnly Property Color( ) As Color Implements IPaintable.Color Get Return myColor End Get End Property End Class
While each interface method needs to be implemented, you don't need to name it the same thing in the implementing class. Look closely and you will see that IPaintable.Completed was renamed "Painted" in the implementation. This feature is nice because "Completed" is vague in regard to the interface it is part of and it is also a common name. When a class implements several interfaces, the name "Completed" could be used in several places.
|only for RuBoard|