Shared boundary between elements of a computing system
In computing, aninterface is a shared boundary across which two or more separate components of a computer system exchange information. The exchange can be betweensoftware,computer hardware,peripheral devices,humans, and combinations of these.[1] Some computer hardware devices, such as a touchscreen, can both send and receive data through the interface, while others such as a mouse or microphone may only provide an interface to send data to a given system.[2]
Hardware interfaces of alaptop computer:Ethernet network socket (center), to the left a part of theVGA port, to the right (upper) adisplay port socket, to the right (lower) aUSB-A socket.
Hardware interfaces exist in many components, such as the variousbuses,storage devices, otherI/O devices, etc. A hardware interface is described by the mechanical, electrical, and logical signals at the interface and the protocol for sequencing them (sometimes called signaling).[3] A standard interface, such asSCSI, decouples the design and introduction of computing hardware, such asI/O devices, from the design and introduction of other components of a computing system, thereby allowing users and manufacturers great flexibility in the implementation of computing systems.[3] Hardware interfaces can beparallel with several electrical connections carrying parts of the data simultaneously orserial where data are sent onebit at a time.[4]
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 orprograms running on the operating system may need to interact via datastreams, filters, and pipelines.[5] Inobject oriented programs, objects within an application may need to interact viamethods.[6]
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.[7] 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.[citation needed]
The interface of a software moduleA is deliberately defined separately from theimplementation 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 moduleB, for example theclient toA, that interacts withA is forced to do so only through the published interface. One practical advantage of this arrangement is that replacing the implementation ofA with another implementation of the same interface should not causeB to fail—howA internally meets the requirements of the interface is not relevant toB, whichis only concerned with the specifications of the interface. (See alsoLiskov substitution principle.)[citation needed]
In someobject-oriented languages, especially those without fullmultiple inheritance, the terminterface is used to define anabstract type that acts as anabstraction of aclass. It contains no data, but defines behaviours asmethod signatures. Aclass having code and data for all the methods corresponding to that interface and declaring so is said toimplement that interface.[9] Furthermore, even in single-inheritance-languages, one can implement multiple interfaces, and hence canbe of different types at the same time.[10]
An interface is thus atype definition; anywhere an object can be exchanged (for example, in afunction ormethod call) thetype of the object to be exchanged can be defined in terms of one of its implementedinterfaces or base-classes rather than specifying the specificclass. This approach means that any class that implements that interface can be used.[citation needed] For example, adummy implementation may be used to allow development to progress before the final implementation is available. In another case, afake or mock implementation may be substituted during testing. Suchstub 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.[citation needed] An interface called "Stack" might define two methods:push() andpop(). It can be implemented in different ways, for example,FastStack andGenericStack—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, theJava language defines the interfaceReadable that has the singleread() method; various implementations are used for different purposes, includingBufferedReader,FileReader,InputStreamReader,PipedReader, andStringReader.Marker interfaces likeSerializable contain no methods at all and serve to provide run-time information to generic processing usingReflection.[11]
The use of interfaces allows for a programming style calledprogramming 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.[12]
Pushing this idea to the extreme,inversion of control leaves thecontext to inject the code with the specific implementations of the interface that will be used to perform the work.
Auser interface is a point of interaction between a computer and humans; it includes any number ofmodalities ofinteraction (such as graphics, sound, position, movement, etc.) where data is transferred between the user and the computer system.
^Bill Venners (2005-06-06)."Leading-Edge Java: Design Principles from Design Patterns: Program to an interface, not an implementation - A Conversation with Erich Gamma, Part III".artima developer.Archived from the original on 2011-08-05. Retrieved2011-08-03.Once you depend on interfaces only, you're decoupled from the implementation. That means the implementation can vary, and that is a healthy dependency relationship. For example, for testing purposes you can replace a heavy database implementation with a lighter-weight mock implementation. Fortunately, with today's refactoring support you no longer have to come up with an interface up front. You can distill an interface from a concrete class once you have the full insights into a problem. The intended interface is just one 'extract interface' refactoring away. ...
^Patterson, D.A.; Hennessy, J.L. (7 August 2004).Computer Organization and Design: The Hardware/Software Interface (3rd ed.). Elsevier. p. 656.ISBN9780080502571.
