A software interface may refer to a wide range of different types of interfaces at different "levels". For example, an operating system may interface with pieces of hardware.
Applications or
programs running on the operating system may need to interact via data
streams, filters, and pipelines. In
object oriented programs, objects within an application may need to interact via
methods.
In practice A key principle of design is to prohibit access to all resources by default, allowing access only through well-defined entry points, i.e., interfaces. Software interfaces provide access to computer resources (such as memory, CPU, storage, etc.) of the underlying computer system; direct access (i.e., not through well-designed interfaces) to such resources by software can have major ramifications—sometimes disastrous ones—for functionality and stability. Interfaces between software components can provide
constants,
data types, types of
procedures,
exception specifications, and
method signatures. Sometimes, public
variables are also defined as part of an interface. The interface of a software module
A is deliberately defined separately from the
implementation of that module. The latter contains the actual code of the procedures and methods described in the interface, as well as other "private" variables, procedures, etc. Another software module
B, for example the
client to
A, that interacts with
A is forced to do so only through the published interface. One practical advantage of this arrangement is that replacing the implementation of
A with another implementation of the same interface should not cause
B to fail—how
A internally meets the requirements of the interface is not relevant to
B, which
is only concerned with the specifications of the interface. (See also
Liskov substitution principle.)
In object-oriented languages In some
object-oriented languages, especially those without full
multiple inheritance, the term
interface is used to define an
abstract type that acts as an
abstraction of a
class. It contains no data, but defines behaviours as
method signatures. A
class having code and data for all the methods corresponding to that interface and declaring so is said to
implement that interface. Furthermore, even in single-inheritance-languages, one can implement multiple interfaces, and hence can
be of different types at the same time. An interface is thus a
type definition; anywhere an object can be exchanged (for example, in a
function or
method call) the
type of the object to be exchanged can be defined in terms of one of its implemented
interfaces or base-classes rather than specifying the specific
class. This approach means that any class that implements that interface can be used. For example, a
dummy implementation may be used to allow development to progress before the final implementation is available. In another case, a
fake or mock implementation may be substituted during testing. Such
stub implementations are replaced by real code later in the development process. Usually, a method defined in an interface contains no code and thus cannot itself be called; it must be implemented by non-abstract code to be run when it is invoked. An interface called "
Stack" might define two methods: push() and pop(). It can be implemented in different ways, for example, FastStack and GenericStack—the first being fast, working with a data structure of fixed size, and the second using a data structure that can be resized, but at the cost of somewhat lower speed. Though interfaces can contain many methods, they may contain only one or even none at all. For example, the
Java language defines the interface that has the single method; various implementations are used for different purposes, including , , , , and .
Marker interfaces like contain no methods at all and serve to provide run-time information to generic processing using
Reflection.
Programming to the interface The use of interfaces allows for a programming style called
programming to the interface. The idea behind this approach is to base programming logic on the interfaces of the objects used, rather than on internal implementation details. Programming to the interface reduces dependency on implementation specifics and makes code more reusable. Pushing this idea to the extreme,
inversion of control leaves the
context to inject the code with the specific implementations of the interface that will be used to perform the work. == User interfaces ==