C# v/s VB.Net Program to interface not to implementaion

Why it is said that "Always program to interface not to implementation"?

The reason is simple. If we program to interfaces, we can change it's underlying implementation at any time without changing the code which is using it. For simple example, we all deal with databases on a daily basis. When we are writing DAL (Data Access Layer) and our track codes point to the IDataAcessLayer the implementations can be anything  .ie it Can be SQLDatAccessLayer,OracleDataAccessLayer etc...Which means at a future point if your project stakeholders decide to change the DB there is no need to change your track code it the application logic projects. Only we need to change the object which is created for IDataAccessLayer.

Challenges in enforcing "Program to interface not to implementation" in large projects

Like any other engineering discipline, its easy to manage and keep the quality, if the team is small. We can have frequent reviews. Mentor them, even monitor closely. When the team grows beyond 100s with half of them are just passed out from college, its really difficult to make sure we are following this principle. This will not a problem, if you are developing a product where you have full control on the release timeline or in a project where you have lavish budget to allocate senior developers for code review. But this is not the case in most of the Indian software service companies.

C# - Enforcing "Program to interface not to implementation"

In programming languages like C# its very easy to make all developers follow the principle. Who ever developing the classes, need to implement the interfaces explicitly. Which means the track developers ( fresher category normally fills this position) cannot refer the interface methods using a class variable which they could have otherwise.

It's simple. Isn't it? the interface members are public by default. No question on that. If we implement it implicitly in a class, the other developers can create the variable of that class and invoke the interface members. Lets see the below code snippet which will give more understanding about explicit interface implementation.

---

    public interface IMyInterface
    {
        void Foo();
    }
    public class MyClass : IMyInterface
    {
        void IMyInterface.Foo()
        {
            Console.WriteLine("MyClass.Foo");
        }
    }
    public class Program
    {
        static void Main(string[] args)
        {
            IMyInterface mI = new MyClass();
            mI.Foo(); //This ensures that the members are only be accessible via interface variable.
            MyClass mC = new MyClass();
            //mC.Foo(); This will cause compilation error.
            //TestMethod();
        }
    }

VB.Net - Enforcing "Program to interface not to implementation"

In C# its easy as there is explicit interface implementation. Even there are more help on the same. But VB.Net doesn't have that concept. So the solution to enforcing 'program to interface..' in VB.Net, is the alternative of explicit interface implementation, similar to C#. And the solution is as follows.

Implement interface members as private in VB.Net to achieve explicit interface implementation.

No need to wonder, thinking that interface members are always public. Read the MSDN page for more details. Below is a code snippet which does the same in VB.Net

---

Public Interface IMyInterface
    Sub Foo()End Interface
 Public Class MyImplementation
    Implements IMyInterface
    Private Sub Foo() Implements IMyInterface.Foo
        Console.WriteLine("MyImplementation.Foo()")
    End Sub
End Class
 Module Module1
    Sub Main()
        Dim mI As IMyInterface = New MyImplementation()
        mI.Foo()'Works
        Dim mC As MyImplementation = New MyImplementation()
        'mC.Foo() ' Doesn't work
    End Sub
End Module

---

It took really long time for me to find out a mechanism to enforce the "Program to interface..." principle in VB.Net.