• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 236
  • Last Modified:

what do they mean when they say code to a interface? does that mean everything should be coded to a interface?

what do they mean when they say code to a interface? does that mean everything should be coded to a interface?
3 Solutions
I means - from a developer point of view:
don't expose any classes, methods or properties and so on that can be accessed by any programmer who works with your library / component. Make all your "operations" available through interfaces that should be used by 3rd party developers.

have a look here (it is a java article, but that does not matter in that case):
Nice question..I will give you a very practical answer. See if this fits your doubt.

In usual business scenarios it often happens that you need to use a third party solution. As a generic example, take database connectivity. To use a third party solution we need following assumptions to be in place and strict when we start coding to use it.

1. Neither party (yourself as the consumer or the DB vendor) is going to expose the 'secret' working code to each other. We just want to use the feature and not understand it (there is much more in my life to understand than some vendors code). How then can i code to use the features if I don't have the third party classes in the classpath?

The solution is that both the parties (you and db provider) will lock on a common contract (which is interface in our case) where the method signatures and input/output parameters are known. Now as a coder we will use (and not implement) this interface in our code and call all the required methods from the interface. We will also add the vendor library in the classpath so that during runtime the concrete class is referenced by the interface.

As you can see this allows delayed development mode too; where a single interface is shared between both vendor and contractor and is then coded by both teams for respective development. The concrete implementation is required only during runtime.

2. How would you like if this contract (interface) is ratified and confirmed by a central body so that all the vendors (the DB providers in above case) code to the same interface. In that case my code never changes at all even though DB providers change. Only change for me then is to change the classpath library. That is JDBC concept for you, Google it.

3. How would you like if the interface is not java interface but an XML (finally its a contract isn't it) which can then be published to the world over internet and can be used by any coding language (or at least ASP.NET). Here we now can talk across languages (Java with ASP.NET).
That is concept of Web Services for you from a very high level.

Of course I simplified the explanation a bit and remove a bit of chaff from the technicality (of JDBC... google it). I hope I answer your query. The statement to take away is [Interface is nothing but a contract between service consumer and service provider.]
Fallowing the idea in calboronster comments. If you have a ddbb connection to sql server and in your code you have an statement like this:

SqlConnection con = new SqlConnection();

Then you can't switch to another ddbb vendor without changing all your references to SqlConnection. But if you use instead:

IDbConnection con =   DbProviderFactories.GetFactory(providerName).CreateConnection();

Here, IDbConnection  is the common contract that every vendor must implement in their database connection. As you're not tied to an specific implementation, switching to other vendor is a trivial work.

Hope this solves your doubts.
Best regards.

Featured Post

Concerto's Cloud Advisory Services

Want to avoid the missteps to gaining all the benefits of the cloud? Learn more about the different assessment options from our Cloud Advisory team.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now