5.2 Versioning

only for RuBoard

An interface is a contract, and contracts are not meant to be broken. It is not hard to fathom that if you change an interface, the waters will get rough. Code that depends on an interface that has been changed will no longer work. Once an interface is published, it is imperative that it does not change. This rule applies to the public and protected interfaces of a class, as well as any interfaces that were implemented by a class.

In the tradition of the open -closed principle, when you need to extend an interface, simply create a new one. Usually, a number is appended to the original interface name . For example, the second version of IPaintable would be IPaintable2 .

Working with interfaces is much easier than it used to be. When creating a new version of an interface, you can inherit from the old version to maintain integrity and add the new functionality to the derived interface. Overloading is also allowed:

 Imports System Imports System.Drawing     Public Interface IPaintable2 : Inherits IPaintable     TransparentFill(color As System.Drawing.Color)     Overloads Paint(color1 As Color, color2 As Color) End Interface 

Old clients can still obtain an IPaintable reference from IPaintable2 , while new clients can use the new interface directly.

The versioning story of interfaces is debatably better than a base class. It is definitely more explicit. When you need something new, you define a new interface. It's as straightforward as that. Old clients can use the old interface, while new clients can take advantage of more recent offerings. Simply adding methods to a base class and sorting things out at runtime is not very safe, nor is it forward thinking. It opens you up to all kinds of failures.

only for RuBoard