Significance of interface learned from Java Collection

Interfaces play an important role in object orientation. However, even if you are taught only the implementation of "interfaces have no implementation, they only define methods!", You cannot realize its importance unless you understand its significance. Therefore, this time, I would like to summarize the significance of the interface by taking the Java Collection as a concrete example.

Significance of interface

In conclusion, an interface stands for "role". In other words, it represents what the interface "behaves".

More specifically ~ Collection interface ~

Now let's take a look at the Collection interface.

Collection The root interface of the collection hierarchy. A collection represents a group of objects that are its elements. Some collections allow duplicate elements, but others do not. Also, some collections are ordered and some are not.

In other words, a Collection is an interface that has a "role" of a group of specific objects. And the Collection itself does not specify whether it can be duplicated or ordered.

Collection inheritance destination ~ Set and List ~

Now let's look at the interfaces that inherit from Collection, Set and List. I think there are many people who are more familiar with this than the Collection.

Set A collection with no duplicate elements. That is, the set does not have an element pair of e1 and e2, which is e1.equals (e2), and has at most one null element. As the name implies, this interface models the mathematical abstraction of sets.

List An ordered collection. Also called a sequence. Users of this interface have precise control over where in the list each element is inserted. Users can access elements by index of integer values (position in the list) and search for elements in the list. Unlike sets, lists usually allow duplicate elements.

To summarize these in a table,

Since Set and List inherit from the Collection class, you can see that they are interfaces with more specific roles.

Interface method

Now let's look at the methods of each interface (see the JavaDoc listed above for definitions etc.). Collection specifies operations for groups such as size (number of elements) and remove (remove elements). Set also basically defines methods like those in Collection, but List defines methods related to indexes such as indexOf (search for the index of the specified element). Since Set does not have the concept of index in the first place (it does not order), index processing is processing that belongs to the role of List. Also, focusing on the method called add, the method defined in Collection is overridden by Set and List, and the explanation of the method is different for each.

In Collection, add is a guarantee of storage, not additional processing. This is because there is a role that is not added if the element to be added already exists like Set, so from the role of Collection, the process of add is "sometimes elements are added and sometimes they are not added. Sometimes, but at least after executing add, I guarantee that the element I'm trying to add is in the group. " Each of Set and List add has more specific contents. This means that each has a more specific "interface role" through inheritance, which makes the "method role" more specific. Overriding a method of an interface doesn't make much sense in the implementation, but it can be said to be overridden to explicitly express the intent of "which interface the method belongs to".

role? what is that? is it delicious?

I hope you understand that each interface and its method expresses some kind of "role". However, the question becomes, "Why is it important to express the role?" Before we explain that, let's take a look at the two codes.

ArrayList<String> list = new ArrayList<String>();
list.add("abc");

List<String> list = new ArrayList<String>();
list.add("abc");

I'm sure many people have seen code like this. Normally, the following writing style is recommended. The reason is that the code below is "more abstract concept-dependent processing".

Why isn't it concrete?

The reason for writing code so that it depends on abstraction is to separate the processing of the interface implementation class and the class that uses it. For example, suppose you want to change the implementation class of List from using ArrayList to LinkedList later. In that case, the first two codes would look like this:

LinkedList<String> list = new LinkedList<String>();
list.add("abc");

List<String> list = new LinkedList<String>();
list.add("abc");

At first glance, both of these two codes seem to have changed the first line. However, considering the second line from the viewpoint of the intention of the code, the code below still has the intention of "adding to List", while the code above changes from "adding to ArrayList" to "LinkedList". It has changed to the intention of "add". Therefore, it is necessary to confirm that the intent of the code has not changed due to the change of the implementation class.

If you write your own implementation class, this will bring even greater utility. As long as it matches the role of the List interface, any internal implementation will do. From the user's point of view, it is possible to write the process under the guarantee that "the implementation class of the List interface implements to satisfy that role". The bottom line is that users can write processes without an implementation class if they only depend on the interface. It is exactly "separation of user and implementation class".

Summary

I think that I have seen various things and grasped the significance of the interface. However, these ideas are based on the assumption that the implementation class is implemented according to the role of the interface, and that role is used to describe the processing of the user. Therefore, it is important to be aware of the role of each interface when implementing it, and you can maximize the benefits by creating your own interface with the role in mind.