Coding to an interface

IamtheWalrus

If I want to use a Java linked list, to make use of the queueing functionality, I would do this:

LinkedList<String> myList = new LinkedList<String>();
        myList.peek();

But if I want code to an interface, I'd prefer to use:

List<String> myList = new LinkedList<String>();

Is the 'code to an interface' rule actually 'code to an interface - when possible'?

Idleater

Unless you specifically want to use the peek() method of linkedlist, I see no reason not to code to the list interface.

Personally I would code to the most generic interface/abstraction possible as a guide and work down the implementation tree when needed.

SionnachRoe

I would consider the rule to be 'Code to the interface'.

If there is a need to use a method in that is not in the interface then most, the interface chosen is incorrect. In the above example, if you need to use the queuing functionality then maybe

Queue<String> myQueue = new LinkedList<String>();
myList.peek();

would be a better choice.

The core concept behind 'Code to the interface' is that we should consider our code in terms of what is does, rather than how it does it. If for example, we think that we wish to work with a queue, then we define our object as a queue which allows/forces to use only queue-like functionality with it. If we find that we are, for example, casting it to a list to do something, then we should re-examine if we really want to use a queue.

jester77

Coding to an interface makes it much easier to change implementation later, especially when you are using a dependency injection framework. You would only need to change it once for you whole app in the module where you provide the implementation. Your unit tests should also run against the interface.

happycoach

SionnachRoe wrote: »

I would consider the rule to be 'Code to the interface'.

If there is a need to use a method in that is not in the interface then most, the interface chosen is incorrect. In the above example, if you need to use the queuing functionality then maybe

Queue<String> myQueue = new LinkedList<String>();
myList.peek();

would be a better choice.

The core concept behind 'Code to the interface' is that we should consider our code in terms of what is does, rather than how it does it. If for example, we think that we wish to work with a queue, then we define our object as a queue which allows/forces to use only queue-like functionality with it. If we find that we are, for example, casting it to a list to do something, then we should re-examine if we really want to use a queue.

+2