Interface programming

Question

In my opinion, you are programming an interface, not a specific class, to limit yourself to using methods that are not part of the interface. This helps if you want to subsequently change the implementation of the interface. (Flexibility) that is.

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

instead

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

Is there a reason that you cannot access methods in ArrayList, such as trimToSize (), that are not part of the List interface, simply because they are not defined in List? Does it look like the class has a public global variable but has no way to access it?

Also, if you decide to change

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

Will there be the only reason you make such a change for performance (I see no other reason)? Since in both cases you can only access specific List List, excluding specific implementation functionality.

Answer 1

People use the interface to hide the details of implementation details. For example, I want to write a function that returns the size of a collection — it could be a list, an array, a map, whatever, I don’t care. I will use pseudo code, this does not apply to Java:

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

Otherwise, I have to implement 'map_length, list_length' and dozens of other methods. And it will blow your code a lot.

Another common example is databases. There are quite a lot of them with various APIs, language queries, performance, etc. I do not know in advance which one they prefer to use in your application. This way you can create a common database interface and use it as a placeholder around your code. Although you hide the exact databases behind the interface, you can switch between different databases without any problems.

I would recommend you read further on inheritance and patterns.

Answer 2

You are right in your explanations.

Programming with interfaces (e.g. APIs) has several interests. The following are some examples:

• Clearer / easier from the point of view of the contract: someone who uses your API will know which function you set and what it can use. This will not help to expose everything just for the reason that “in case ...” No, if you are developing a business, this is most of the time for specific reasons / needs. Even when you create some technical layers, it’s better to expose only what you should use as a common goal, especially when you can have different contract implementations (having only one implementation does not mean that you don’t need an API by the way )
• This is safer: you avoid the complexity of use and therefore use the script.
• Better for maintenability: as you said, you can change your implementation without affecting the client using your API (if it is properly designed, of course)
• As part of the organization of the project, it also allows you to divide your project into several modules (modules) and take into account the requirements of the module.
• In terms of creating / deploying applications, it also allows you to separate components, and then only change / rebuild / deploy parts of your global application.

There are many benefits to API programming.

About the list and various implementations, the reasons why some methods do not exist, and the API may be:

• Or the people who did this did not think about possible future use
• Or maybe the function you are requesting is too specific to be offered as a public method for this API.
• Or maybe this is not (or should not be) the responsibility of this class for your specific need.
• Or maybe the other utility classes in List are already doing what you need.
• Or any other good or bad reasons.

Answer 3

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 the interfaces, but at the business layer you don’t really need it if it’s not good causes.