Is programming against interfaces in Java the same concept as using header files in C/C++?

The java code I'm working on at the moment has often a structure like

file Controller.java:

interface Controller {...}

file ControllerImpl.java:

class ControllerImpl implements Controller {...}

But for every interface there is only one implementation. Isn't that the same as using header files in C/C++ where I have the code split into files like

Controller.hpp
Controller.cpp

From what I know, header files in C/C++ have been introduced to help the compiler, which is not necessary anymore in Java. Also header files should help with the readability of the code, but having a modern IDE with folding and outline view this is also 开发者_开发技巧not a necessity anymore.

So why do people again introduce header files in Java through the back door by programming against interfaces?

No. In C++, files (headers) are not the same as classes.

Programming against interfaces as in Java can be done in C++, too, by programming against abstract base classes.

However, the Java term of "interface" is quite restricted. Basically, any function declaration is an interface:

void call_me(int times); 

As are, of course, classes and other types.

In C++, you group such things in headers, so an interface can consist of one header. However, it might just as well consist of multiple headers.

Interfaces doesn't come from a desire to keep header files.

Interfaces the closest Java comes to supporting http://en.wikipedia.org/wiki/Design_by_contract

interfaces are more like abstract base classes in c++.

the reason they are often used in java is that multiple inheritance does not exist in java (both were design decisions). c++ supports multiple inheritance, so... it can accomplish the problem that way (and via a few others).

once a class implements an interface in java, then it can be passed as the type. the same principle in c++, although the written implementation is slightly different.

so, the interface simplifies the programming process, since arbitrary objects may be passed, as long as they implement the interface (or in c++ are derived from a specific class). with an interface, you do not need to derive from a common base class -- it's a very simple, and usable design. multiple inheritance in c++ is a pitfall for many developers.

In Java, an interface defines a contract, while a class provides an implementation of a contract.

Most contracts have only one meaningful or relevant implementation; some even assume a specific implementation and do not allow any other. Those contracts and their implementations are defined together in classes, without any interfaces. Example: java.lang.String.

On the other hand, some contracts do not make any assumption on the possible implementations. Those are defined in interfaces. Partial implementations can be defined in abstract classes, and typical complete implementations can be defined in classes, but the fact that the contract is defined in an interface allows you to write your own implementation of that contract and use it wherever an instance of the contract is expected.

At the file level, both an interface and a class are compilation units and deserve their own file.

As you now hopefully understand, the distinction between header files and implementation files in C++ is very different.

No, programming against interfaces has nothing to do with whether or not you use header files.

Defining an interface explicitly will allow evolving the program on both sides independently. The 'interface' of a code body denotes the contract to which it obeys.

Programming languages never fully support interface definitions, they merely have some syntactic sugar to handle the type-correctness aspect. Performance aspects, for one, are most of the time unspecificable, just like complexity rules etc... (C++ standard defines some complexity requirements for the containers and algorithms).

This limited support has left Java with the keyword interface: since object orientation is about grouping functionality into classes, it made sense to couple the concept of an 'interface' to something that groups member function definitions. Several classes can implement a given interface, and a class can implement many interfaces as well.

In C++, they didn't even bother to explicitly add 'interface' to the language. The thing that comes closest to the 'class interface' of Java is a pure abtract class: a class with only pure virtual member functions. Since C++ supports multiple inheritance, classes can implement multiple of these 'interfaces'.

When it comes to the separation of your code into headers and source files, that's totally irrelevant to the interface concept. But indeed: in C++, the 'calling contract' is mostly specified in a header file. And indeed, that makes for shorter compilation times (less IO). But that's a compiler-technical aspect.

The question is good, there is a connection between header files and classes/interfaces/OO programming, beyond the raw syntax of the languages.

Proper C++ program design:

• Put one class declaration, and one only, in a h-file.
• Give said h-file the same name as the class declared.
• Put the class definition in a cpp-file with the same name as the h-file.

Proper Java program design:

• Same as for C++, though also put interfaces in files of their own.

Proper C design:

• In the h-file, declare functions belonging to a particular "code module".
• Put the function definitions in a c-file with the same name as the h-file.
• All variables you would have declared as private/protected if writing C++/Java should either be truly private through the concept of "opaque type/pointers", or be placed at file scope and declared static, so that they can be shared between functions within the "code module" (though that makes the code non-reentrant).

If you don't use the above intimate connection between classes and h-files, there is a fine chance that your program is an unreadable mess, no matter how elegant your OO design is.

Header files in C/C++ has nothing to do with classes or interfaces at all.

A header file is more like the reference you add to your project, or the using statement.

It's an instruction to the compiler that the object (class) and function declarations in the header file exist so that the compiler can compile the file without having to look through the whole project.

A header file in C++ can contain classes or function definitions, or macros, or enums... or many other things, but is conceptually very different from classes or interfaces.

You can use interfaces in C++, as shown here: How do you declare an interface in C++?.

...and those definitions are placed in header files, but the header file itself is something else.

The reason to use interfaces instead of inheritance is that many classes can implement an interface or many interfaces but you can only inherit from one class.

So if you have many objects, that is, to be interchangeable, you would end up with a very complex class hierarchy - while with interfaces, the classes can be built completely separately with only the interface linking them.