What is Interface-based framework?

Question

I was going through Effective Java and reading static factory methods for creating objects. Its chapter 2, Item 1. There in the advantage no. 3, the writer has mentioned like

Hiding implementation classes in this fashion can lead to a very compact API. This technique lends itself to interface-based frameworks, where interfaces provide natural return types for static factory methods.

I could not understand what the interface-based frameworks are?

Answer 1

Maybe rephrasing it a bit would help:

an interface-based framework is a framework giving the user/client lib access to interfaces only while actually delivering classes implementing those interfaces.

The benefit of this approach consists in giving the implementor full control over the implementation and giving the client a stable API at the same time.

I encountered an example lately, where the client gets an XmlProcessor from an API method. Inside the framework, there are three totally different implementation of this processor: a DomXmlProcessor , SaxXmlProcessor and a VtdXmlProcessor . The details of the individual implementations are of no concern to the client and can be switched any time.

Answer 2

Interface-based frameworks are those frameworks which are designed with Interface and its implementation.

Collection framework is an nice example of Interface-based frameworks.

Hiding implementation classes in this fashion can lead to a very compact API

You just create a interface

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

your implementor will take care of implementation.

Your API consumer will direcrtly use interface like we do in collection

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

Also See

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

Answer 3

Frameworks that expose mainly interfaces to their users (rather than concrete implementations)

Since you mentioned Bloch, I'll give an example with the collections framework. You can see the Collections class has synchronizedX(..) , unmodifiableX(..) , singletonX(..) methods. 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 tons of implementations that you don't need to know about.

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

Answer 4

When you design software, there are core design principles to help manage the complexity involved in a such complex task.

One of theses core principles is to subdivide complex problems into smallers ones, easier to manage and understand.

An interface is in fact a contract. It defines the services one class must conform to and how to use it. The interface hide the implementation details of one or several possible implementations of the contract.

A typical Java application will be designed with interfaces to model the core contracts provided by the different parts of the software. Implementations detail is hidden and thus allow to reduce the complexity.

To be more concrete, lets say you design an accounting application. All accounts offer the same basic services: get the current balance, credit or withdraw money, request a summary of past operations. You can define an interface like that all sort of account will conform to:

public interface Account {

  double getBalance();

  void credit(double amount);

  void withdraw(double amount);

  List<Operation> getOperations(Date startDate, Date endDate); 

}

With this definition, it is easy for example to provide a user interface that allow a user to manage it's accounts. In fact there are differences between check account, credit card account. You will have to manage differently account present directly in the bank database, or distant accounts from other banks. One will be a direct operation, another one would use a network protocol of some kind to perform the operation.

But from your point of view, all you need is that the contract is fulfilled. And you can work on accounts. The details on how a specific account operation is done is not your problem.

This is fancy and nice, but a problem remain. How do you obtain your accounts? That's it a discount account from another bank is surely different from a local account. The code is different. And the way to create it too. For the distant account, you need for example the network address to the other bank server... The other one could require a database ID.

Each time you need to have an account, you can explicitly recreate it, or obtain it with all implementation details. Getting a distant account or local account being very different.

Isolating this complexity in a part of your application is a good practice. It is conform to subdivide complex task into smaller, simpler ones.

I given the example of the 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. So we have common "good ways" of doing it in a maintainable and clean fashion.

The code that manage the complexity of creating of obtaining a specific object, hiding in fact how the object was constructed or given is a called a factory.

Combining the factory (that hide the complexity of creating/finding objects) and interface (that hide the complexity of each object implementations), if the basis of tool Java programmers use to manage software complexity.