Programming to interface

Question

From my understanding, you program to an interface rather than a concrete class to restrict yourself from using methods that aren't part of the interface. This helps in the case you want to change the implementation of said interface later on. (Flexibility) i.e.

    List myList = new ArrayList(); // programming to the List interface

instead of

    ArrayList myList = new ArrayList(); // this is bad

Is the reason you can't access methods in ArrayList such as trimToSize(), that aren't part of the List interface, simply because they're not defined in List? Is it similar to as if a class had a public global variable but no method to access it?

Also, if you do decide to change

    List myList = new ArrayList();
    //into
    List myList = new LinkedList();

Would the only reason you would make such a change be for the performance (I see no other reason)? Since in both cases you'd only be able to access the List defined methods, excluding the concrete implementation's extra functionalities.

Aside from the global variable bit, you're on the right track. — shmosel, Mar 07 '17 at 08:56
I guess it's because I imagine that since myList is just a reference variable to arraylist, all the methods of arraylist still exist in memory, but they just can't be _all_ be accessed. — CheeseBites, Mar 07 '17 at 09:18

score 1 · Answer 1 · answered Mar 07 '17 at 09:01

People use interface to hide details of details of implementation. For example, I want to write a function that returns size of a collection - it can be a list, an array, a map, anything at all, I don't care. I'll use a pseudo-code, it's not relevant to Java:

int length (Collection c) {
  return c.size();
}

Otherwise, I have to implement 'map_length, list_length' and dozens of other methods. And this will blow up your code dramatically.

Another common example - data bases. There quite a lot of them with different API, request languages, performance, etc. I don't know ahead, which one prefer to use in your application. So you can create generic data base interface and use it as 'a placeholder' around your code. While you hide exact DBs behind an interface, you can switch between various DBs without any issues.

I would recommend you reading further on inheritance and patterns.

kij · Answer 2 · 2017-03-07T09:14:13.003

You are right in your explanations.

Programming with interfaces (i.e API) has several interests. Below are few of:

It clearer/simpler in term of contract: Somebody who uses your API will know which feature you exposed and so what he can use. It does not help to expose everything just for the reason "in case of..." No, if you are designing a business, it is most of time for specific reasons / needs. Even when you are building some technical layers, it is still better to expose only what you what to be used as a general purpose, especially when you can have different implementations of a contract (having only one implementation does not mean you don't need API interface by the way)
It is safer: You avoid complexity of usage, and so use scenario.
Better for maintenability: as you said you can change your implementation without impacting client that use your API (if it is correctly designed of course)
In term of project organization, it also enables you to split your project(s) into several module(s) and introduceS module responsabilities.
In term of application building / deployments, it also enables you to seperate components and then to change / rebuild / deploy only parts of your global application.

There are lot of Benefit when programming by API.

About List and different implementations, the reasons why some methods does not exists and the API can be:

Either people who did it did not think about possible future usage
Or, maybe the feature you ask for is too specific to be proposed as a general public method on this API
Or, maybe it is not (or should not be) the responsability of such a class to do your specific need
Or, maybe other utility classes on List already do what you need
Or any other good or bad reasons

score 0 · Answer 3 · answered Mar 07 '17 at 09:10

I would say that it really depends on your situation, there is only one rule "Dependency Inversion", for example, if you are writing business code then the presentation layer should implement interfaces, but in the business layer you don't really need it unless there is a good reason.

Programming to interface

3 Answers3