Interface Guidelines Definition:

Proper Use of Interface Contracts for Implementing Concrete Types

Interface Guidelines Justification:

Interfaces are probably the most misunderstood Software Entity Type by most Developers.

Proper use of Interfaces will allow a Developer to design to Abstractions rather than Concretes.

This creates decoupled solutions that are less costly to maintain throughout the Life Cycle of the developed application.

Interface Guidelines Convention Standards:

Most Developers can probably recite back a version of the academic answer to “What is an Interface in C#?“.

“An Interface is a Contractual Agreement

… Between a Software Entity,

a Class or a Struct,

… To Implement the Concrete Behaviors

Defined in the Signature Abstractions

… For Properties, Methods, Indexers or Events

Declared within the C# Interface Type”

What is the real value of an Interface in a software development environment?

The first concept we need to understand is the difference between “Class Behavior Inheritance” and “Interface Behavior Inheritance“.

1. Class Inheritance:

   All derived child classes must have an “Is A” relationship to the base class.

   This states that a derived Class is an extension of the functionality of the Base Class.

   The Liskov Substitution Principle states that a Derived Class must be substitutable for it Base Class without adversely affecting the functionality of the consuming software module.

   This is only possible if the derived Class has an “Is A” relationship for its inherited behaviors.

   Class Inheritance should only be used for Polymorphism when modelling a point of view, as in an “Is A” relationship.

2. Interface Inheritance

   Sometimes called “Composition” inheritance

   All Classes and Structs that implement an Interface agrees to comply with the Signatures provided within the Interface

   They agree to add the Required Functionality for those Contract Signatures.

   This creates a “Behaves Like” Inheritance Relationship.

   The implementing Class or Struct agrees to Implement Code that results in the behavior fulfilling the contract.

   An Implementing Type does not have to have an “Is A” relationship to the Interface, only common behaviour

Interfaces provide the following benefits to the developer’s design:

1. Forces a Developer, using a Design Pattern, to comply with a structure that can be repeated to ensure proper use of the Design Pattern.

2. Allows for defining Entity Types by abstractions that do not define run-time concretes.

3. Create a vehicle for creating collection of related Types at run-time. Reflection can be used to create candidates for instantiation based on runtime conditions without any knowledge of the concretes at compilation time.

4. Interfaces can implement other Interfaces for extending the contracts of existing Interfaces. This creates an Interface Inheritance structure that can be namespace managed for decoupling functionality requirements.

5. The accessors of a Class can be managed using an Interface for Property and Indexer. By defining the get; and set; Accessor in the Interface immutable data members can be guaranteed.

All Interfaces must be public and cannot contain static signatures.

They cannot contain constants, fields, and operators along with instance constructors, destructors or any Entity Types directly.

You use Properties signature to define return types from the Property Method with its accessors get; and set;. 

The Modern Developer’s Interface Standards:

Interfaces are a powerful tool to manage Software Entity Types.

There is no need to create an interface for every Class Type created, just when any of the above benefits can be realized in your solution.

Think about how your Types will be consumed within the assembly and by outside modules. Use Interfaces as Abstractions to those Implementations.

Use Interfaces to Prevent a Type from Being Used in a Fashion Not Intended