After exposure to Java, various books, articles, and platforms have emphasized the importance of interface oriented development. At work, you probably spend most of your time defining the IService interface and then implementing ServiceImpl, but after writing a lot of code like this, you don’t seem to see any particular benefit in such an interface.

Perhaps many friends who are exposed to Java, have more or less the above feeling, feeling interface oriented seems to be decoupled, but this decoupling does not seem to make much sense. Combined with the actual development, to sum up some of their own understanding.

Abstraction and decoupling

Two very important concepts in programming, abstraction and decoupling, are what interface oriented development is all about.

The interface approach mentioned at the beginning of this article, 95% of the scenarios are actually meaningless, usually in the project service layer business, in fact, there is no need for abstraction. Since a service provides concrete business capabilities for a Web interface, a simple Web interface might just pass parameters and call the service implementation directly, so 95% abstraction doesn’t really make much sense.

Good abstraction

There are many abstractions in the JDK, such as the most commonly used List

and Map

. Map is an interface that is based on the Map the abstract implementation of the interface has a HashMap/TreeMap/Hashtable/SortedMap, the Map is an abstract, it defines the Map types of data should be ability, such as: Get/put/remove/putAll/clear, and so on, but the same interface methods, different implementation classes have different characteristics, such as whether to allow the key is null, it did not elaborate.
,>

With the Map abstraction, a unified data structure is defined: As long as it’s a Map object, we all know that get/ PUT /remove functions are the same. Without this layer of abstraction, different implementations of the same PUT function could be developed by different people, with many different names like PUT/Add /set/input and so on, which would be confusing to use.

Interfaces in business development

Like the underlying tools and code, are using a lot of abstraction, but in business development does not seem to need this kind of too strict abstraction, then interface oriented development for business development is still meaningful?

Make sense!!

The above abstraction of services is unnecessary, but in order to prevent such a need during the development of projects, almost all projects are also developed in terms of interface and interface implementation, which is one thing.

There is also the most used place is RPC interface, RPC interface is the business services extracted from an API module, in this Modle only defined interface, input and output parameters. The RPC that needs to call the service only needs to refer to this API Module, and the input and output parameters are agreed between the two services. The consumer does not need to pay attention to how the interface is implemented. No matter how the producer’s implementation is upgraded, as long as the agreed interface remains unchanged, the consumer does not need any change. This uses interfaces to achieve decoupling. Without interface decoupling, every time a producer’s internal logic is adjusted, the consumer has to cooperate with the upgrade, which is a nightmare.

Middleware abstraction

In the development process of the project, various middleware technologies will be used, such as cache, database, file server, MQ, etc. With the development of the project, it is inevitable that technology selection and replacement will occur. For example, the following file server options are available: FastDFS, minio, ali SSO, FTP file server, etc., may along with the development of the business, at the beginning of the project choice of don’t work for the middleware products, need to replace new technology products, if there is no abstract and decoupling design, calls the mixed concrete implementation of the middleware in business code, will be very difficult to replace.

This can be abstracted using interfaces, such as file servers. Although there are a variety of products, these parameters are generally common when uploading files, such as file flow, file name, save path, etc. If SSO products are used, there may be the concept of buckets. By abstracting the function of file uploading into an interface, the business layer takes advantage of the dependency injection feature of the Spring Framework and only needs to care about the interface, not the concrete implementation class. In this way, technical products can be replaced without affecting services.

Similarly, ORM frameworks can use ORM frameworks such as Mybatis or JPA with no impact on business code through a layer of interface abstraction. After the cache is abstracted through the interface, you can also choose to use the local cache or Redis cache.

The goal is to decouple the business implementation from the middleware invocation implementation.

The last

Abstraction, decoupling, and the use of interfaces go far beyond that. These are just some simple thoughts during personal work, and I would like to share them here. If there is any incorrect understanding, we welcome to correct it.