I often hear/read about interfaced based programming but I am not exactly clear on what that really means. Is interfaced based programming an actual stand alone topic that
It's basically a matter of expressing your dependencies in terms of interfaces instead of concrete classes (or worse, static methods). So if one of your classes needs to perform authentication, it should be provided an IAuthenticator
(or whatever).
This means that:
See if these very popular discussions help:
What is the best analogy to help non-oop developers grok interface based programming?
Why would I want to use Interfaces?
When are interfaces needed?
When should one use interfaces?
What is the purpose of interfaces?
Good Case For Interfaces
What does it mean to “program to an interface”?
From a very abstract view, interface based programming is akin to the components used by a plumber (pipe joints and pipes).
As long as the pipes and the joints are manufactured according to the interface specified (the number of threads and the spacing, etc) various manufactures can provide joints to pipes that were potentially manufactured by some other vendor (but adhering to the aforementioned joint/pipe interface).
Thus, there is more interoperability of components and freedom for the plumber to choose from various vendors, price ranges etc in order to create a functional plumbing system.
Replace the pipes and joints with software components and the parallels are astonishingly simple.
This is something that I don't recommend using heavily in C# development.
Interface-based programming is basically programming to interfaces. You develop the interfaces you're going to use an Contracts, and the actual implementation of the interfaces is hidden behind these contracts.
It was very common prior to .NET, as the best way to get reusable components in Windows was via COM, which worked via interfaces everywhere. However, given .NET's ability to support multiple languages with a single runtime (the CLR), as well as it's superior support for versioning when compared with native code, the usefulness of interface based programming is lessened dramatically when you're programming in C# (unless you're trying to make COM components, in which case, you'll still be creating the COM interfaces indirectly from your C# classes).
If you google for interfaces, you will find plenty of information about how useful interfaces may be.
The concept is to define clear interfaces, which will be used by the various components/parts/classes/modules to communicate and interact. Once you have defined what should be the input/output of these interfaces, you can let the various teams to develop whatever is needed to fulfill the interface requirements, including the input/output testing, ... etc
If you follow this pattern, various teams can start developing their part without waiting for the other parts to be ready. In addition to that you can use Unit testing (using fake objects to simulate the other parts which you are not developing, and test your part).
This method is quite the standard for any new programming project and everybody will take this for granted.
What you refer to as "interface based programming" is more commonly referred to as programming to an interface. Here is an example below. The benefit is hiding the actual implementation of the interface and allowing your code to be more flexible and easily maintained in the future.
YourInterface foo = CreateYourInterface();
foo.DoWork();
foo.DoMoreWork();
CreateYourInterface() would return a concrete implementation of YourInterface. This allows you to change the functionality of the application by changing one line:
YourInterface foo = CreateYourInterface();