CODEWITHSUNDEEP
javaapiclassinterface
Pops
Pops

Reputation: 30868

Why do some APIs provide mostly interfaces, not classes?

Some Java APIs provide a large number of interfaces and few classes. For example, the Stellent/Oracle UCM API is composed of roughly 80% interfaces/20% classes, and many of the classes are just exceptions.

What is the technical reason for preferring interfaces to classes? Is it just an effort to minimize coupling? To improve encapsulation/information hiding? Something else?

Upvotes: 2

Views: 258

Answers (5)

Ayusman
Ayusman

Reputation: 8739

One of the best example is java.sql package.

The reason is: when the designer has a clear idea in mind as to what needs to be done and how the entire application [yet to be designed] structured they provide this idea through an API as a bunch of interfaces.

For example: when SUN (now oracle :-( ) publishes the API for JDBC, the entire SQL package (well most of it) is just interfaces with interoperability very well defined; but the actual vendor of the DB/RDBMS knows what to do so that they achieve the results as expected in the API.

Hence you can write ur java and DB interaction separately while the Database vendor writes the database separately. The vendor just has to write a driver that meets the API (interfaces) standard with out telling you how he did it.

Yet ur application and the DB interoperate with out any problem [well most of the time ;-)]

it's a long answer but hope this helps. Thanks,

Ayusman

Upvotes: 0

Puppy
Puppy

Reputation: 147036

The number of interfaces relative to the number of classes isn't really that important if each class implements a large number of the interfaces.

Upvotes: 0

OscarRyz
OscarRyz

Reputation: 199333

They are designed for 3rd parties to provide the implementation.

A classic and successful example is JDBC ( 22 interfaces 7 concrete classes )

The idea is to provide a .. well.. programmer interface ( API ) so the clients ( the ones that use the code ) may freely relay on the features these API provides without worrying about the underlying implementation.

Other reason is, there might be an existing provider ( ie. FutureSQL ) which still doesn't exist, but it may implement this interfaces and you'll be able to use it.

Upvotes: 3

Athens Holloway
Athens Holloway

Reputation: 2203

Its likely, the framework/API was developed with Dependency Injection, extensibility, low coupling and high cohesion in mind

Upvotes: 0

Eric Petroelje
Eric Petroelje

Reputation: 60559

It would be to maximize their flexibility in changing the underlying classes behind the scenes.

As long as the interfaces/contracts remain the same, they can change the implementation classes all they want without worrying about affecting people who are using their library.

Upvotes: 9

Related Questions