What is an interface-based infrastructure?

Question

I went through efficient Java and read the static factory methods for creating objects. Its chapter 2, paragraph 1. There, in the advantage is not. 3, the writer mentioned how

Hiding implementation classes this way can lead to a very compact API. This method lends itself to interface interfaces, where interfaces provide natural return types for static factory methods.

I could not understand what interface interfaces are?

Answer 1

Maybe rephrasing it a little would help:

an interface-based infrastructure is an environment that provides user / client access to interfaces only when classes that implement those interfaces are actually provided. The advantage of this approach is to give the developer complete control over the implementation and provide the client with a stable API at the same time.

Recently, I came across an example when a client receives an XmlProcessor from an API XmlProcessor are three completely different implementations of this processor inside the structure: a DomXmlProcessor , SaxXmlProcessor and a VtdXmlProcessor . Details of individual implementations are not customer specific and can be switched at any time.

Answer 2

Interface-based frameworks are those structures that are designed with an interface and its implementation.

The structure of the collection is a good example of front-end frameworks.

Hiding implementation classes this way can lead to a very compact API

You just create an interface

 interface Animal{ public void eat();//hiding the implementation public Animal getAnimalInstance();//factory method } 

your developer will take care of the implementation.

Your consumer API will directly use the interface, as in the collection

 List<String> list = new ArrayList<String>(); 

Also see

• when-best-to-use-an-interface-in-java

Answer 3

A framework that displays mainly interfaces for its users (rather than specific implementations)

Since you mentioned Bloch, I will give an example with a collection map. You can see that the Collections class has methods synchronizedX(..) , unmodifiableX(..) , singletonX(..) . These are static factory methods, and there are a lot of them, but they only return interfaces - List , Map , Set , SortedMap . Behind the scenes, there are many realizations you don't need to know about.

Another example (but without focus on static factories) is the JDBC API. There are almost no classes there - Connection , Stetement , PreparedStatement , ResultSet , etc. All interfaces. This allows many implementations to exist for different databases, without any differences. (Imagine that you had to use code in your classes, for example, MySQLStatement , OracleConnection , etc.)

Answer 4

When developing software, there are basic design principles that help to cope with the complexity associated with such a complex task.

One of the main principles is the division of complex problems into smaller ones, they are easier to manage and understand.

The interface is actually a contract. It defines the services that one class should correspond to and how to use it. The interface hides the implementation details of one or more possible contract implementations.

A typical Java application will be developed with interfaces for modeling the basic contracts provided by various pieces of software. Implementation details are hidden and therefore reduce complexity.

To be more specific, let's say you are developing an accounting application. All accounts offer the same basic services: receive current balance, loan or withdraw money, request a summary of past operations. You can define an interface like this, all kinds of accounts will match:

 public interface Account { double getBalance(); void credit(double amount); void withdraw(double amount); List<Operation> getOperations(Date startDate, Date endDate); } 

Using this definition, it’s easy, for example, to provide a user interface that allows a user to manage their accounts. In fact, there are differences between a check, a credit card account. You will have to manage differently the account located directly in the banking database, or deleted accounts from other banks. One of them will be direct, the other is to use some kind of network protocol to perform the operation.

But from your point of view, all you need is that the contract is completed. And you can work on accounts. Information about how a particular account operation is performed is not your problem.

It is fashionable and nice, but the problem remains. How do you get your bills? The fact that this is an account from an account of another bank, of course, differs from the local account. The code is different. And a way to create it too. For a remote account, you need, for example, a network address on another bank server ... Others may require a database identifier.

Every time you need to have an account, you can explicitly recreate it or get it with all the implementation information. Getting a remote account or local account is very different.

Isolating this complexity in part of your application is good practice. It is consistent with breaking up a complex task into smaller, simpler ones.

I gave an example of an accounting application, but in fact we can be more general. Creating objects and retrieving already created objects is a very common problem in any software. Thus, we have common “good ways” to do this in a convenient and clean way.

The code that controls the complexity of creating a specific object, actually hiding how the object was created or defined, is called factory.

The combination of a factory (which hide the complexity of creating / searching for objects) and an interface (which hide the complexity of implementing each object), if the Java programmer’s tool base is used to control software complexity.