This is 2nd in a series of articles on .NET design practices.  This article concentrates on classes and interfaces and how they differ and how/when to implement.

An interface defines the signatures for a set of members that implementers must provide.  Interfaces cannot provide implementation details for the members.  Interfaces provide definitions for events, indexers, methods and/or properties.  Interfaces are inherited by classes and structures which must provide an implementation for each interfaces’ members.  The Interface doesn't actually do anything but only has a signature for interaction with other classes or interfaces.

By convention interfaces are prefixed with a capital “I”.  Interfaces differ from abstract classes in that they only define the member definitions (never the implementations).  Interfaces are good for designing components that are interchangeable as they all expose specific public members in a consistent manner.  This is key to understanding the value of interfaces.  The ability to have a series of components with similar properties and methods (aka. contracts) promotes consistency and information to the developer.


Interfaces may also be inherited by other interfaces and any class or structure that implements an interface much implement all members in an entire interface inheritance chain.  Interfaces in C# are provided as a replacement of multiple inheritance. Because C# does not support multiple inheritance, it was necessary to incorporate some other method so that the class can inherit the behavior of more than one class.


Danger, Danger: If the interfaces are poorly designed and have to change (add functionality) after they have been deployed it WILL cause cascading breaks in existing classes that have implemented them.  As such, interfaces need to be carefully designed.  Alternatives to the interface approach is utilizing abstract classes.   Similarly, modifications to abstract classes can have have breaking issues of derived classes if care is not taken.  Interfaces vs. Abstract classes will be covered in a future article but note that both have things we need to watch for when making modifications. 

Interfaces however are contracts that the developer is keenly aware of and as such he/she knows that they cannot change and so just the existence of the interface ensures that everyone is aware of how consistent they must be maintained.  In this essence the usage of an interface establishes a consistent contract (methods and properties) that will not be changed.
Remember, an interface tells a class that another class implements all the methods contained in an interface, therefore, you do not have to know what type of object it is, only that it implements the interface.  With interfaces we are moving away from considering classes in terms of what they are, and starting to think about them in terms of what they can do.
So, interfaces are good for establishing similarities between unrelated classes without locking in relationships between classes.  As such they declare methods that one or more classes (of different types) are expected to implement.  Interfaces are similar to base classes in that they provide structure to other derived classes and both can be used for polymorphism.
Interfaces are different than base classes in that:

• A class can inherit only one base class, but it can implement many interfaces
• A base class can contain implementation, an interface cannot
• Interfaces can only contain Methods, Properties, Indexers, and Events. They cannot contain fields or constants (which are used for implementation)

 

Classes vs. Interfaces Guidelines

Classes define both member signatures and implementation details for each member. Abstract (MustInherit in Visual Basic) classes can behave like interfaces or regular classes in that they can define members, and they can provide implementation details but are not required to do so. If an abstract class does not provide implementation details, concrete classes that inherit from the abstract class are required to provide the implementation.

While both abstract classes and interfaces support separating contract from implementation, interfaces cannot specify new members in later versions while abstract classes can add members as needed to support additional functionality.
Do favor defining classes over interfaces.

• In later versions of your library, you can safely add new members to classes; you cannot add members to interfaces without breaking existing code.

Do use abstract (MustInherit in Visual Basic) classes instead of interfaces to decouple the contract from implementations.
Do define an interface if you need to provide a polymorphic hierarchy of value types.

• Value types must inherit from ValueType, and can inherit only from ValueType, so they cannot use classes to separate contract and implementation. In this case, you must use an interface if your value types require polymorphic behavior.

Consider defining interfaces to achieve an effect similar to that of multiple inheritance.

• If a type must implement multiple contracts, or the contract is applicable to a wide variety of types, use an interface.