|This article needs additional citations for verification. (May 2010)|
In computer science, an interface is the point of interaction[vague] with software, or computer hardware, or with peripheral devices such as a computer monitor or a keyboard. Some computer interfaces such as a touchscreen can send and receive data, while others such as a mouse, microphone or joystick can only send data.
Hardware interfaces exist in computing systems between many of the components such as the various buses, storage devices, other I/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). A standard interface, such as SCSI, decouples the design and introduction of computing hardware, such as I/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. Hardware interfaces can be parallel where performance is important or serial where distance is important.
A software interface may refer to a wide range of different types of interface at different "levels": an operating system may interface with pieces of hardware. Applications or programs running on the operating system may need to interact via streams, and in object oriented programs, objects within an application may need to interact via methods.
Software interfaces 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. Such software interfaces provide access to computer resources (such as memory, CPU, storage, etc.) of the underlying computer system.; the 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.
The types of access that interfaces provide between software components can include: constants, data types, types of procedures, exception specifications and method signatures. In some[which?] instances, it may be useful to define public variables as part of the interface. It often also specifies the functionality of those procedures and methods, either by comments or (in some[which?] experimental languages) by formal logical assertions and preconditions.
The interface of a software module A is deliberately kept separate 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.. Any other software module B (that can be referred to as a client to A) that interacts with A is forced to do so only through the interface. One practical advantage of this arrangement is that replacing the implementation of A by another one that meets the same specifications of the interface should not cause B to fail—as long as its use of A complies with the specifications of the interface. (See also Liskov substitution principle.)
Software interfaces in object-oriented languages
In object-oriented languages, the term "interface" is often used to define an abstract type that contains no data, but exposes behaviors defined as methods. A class having all the methods corresponding to that interface is said to implement that interface. Furthermore, a class can implement multiple interfaces, and hence can be of different types at the same time.
An interface is hence a type definition; anywhere an object can be exchanged (in a function or method call) the type of the object to be exchanged can be defined in terms of an interface instead of a specific class. This allows later code to use the same function exchanging different object types; hence such code turns out to be more generic and reusable.
Usually a method in an interface cannot be used directly; there must be a class implementing that object to be used for the method invocation. For example, one can define an interface called "Stack" that has two methods:
pop() and later implement it in two different versions, say, FastStack and GenericStack—the first being faster, but working with a stack of fixed size, and the second using a data structure that can be resized, but at the cost of somewhat lower speed.
This approach can be pushed to the limit of defining interfaces with a single method; e.g. the Java language defines the interface Readable that has the single
read() method and a collection of implementations to be used for different purposes, among others: BufferedReader, FileReader, InputStreamReader, PipedReader, and StringReader; or even less, marker interfaces like Serializable contain virtually nothing.
In its purest form, an interface (like in Java) must include only method definitions and constant values that make up part of the static interface of a type. The C# language also permits the definition to include properties owned by the object, which are treated as methods with syntactic sugar, but no constants (in contrast to Java), constructors, destructors, fields, nested types, or operators.
Programming to the interface
The use of interfaces allows a programming style called programming to the interface. The idea behind this 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. It gives the programmer the ability to later change the behavior of the system by simply swapping the object used with another implementing the same interface.
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.
- Abstraction inversion
- Application binary interface
- Application programming interface
- Business Interoperability Interface
- Computer bus
- Implementation (computer science)
- Implementation inheritance
- Inheritance semantics
- Modular programming
- Software componentry
- User interface
- Virtual inheritance
- interactive interface
- Blaauw, Gerritt A.; Brooks, Jr., Frederick P. (1997), "Chapter 8.6, Device Interfaces", Computer Architecture-Concepts and Evolution, Addison-Wesley, pp. 489–493, ISBN 0-201-10557-8 See also: Patterson, David A.; Hennessey, John L. (2005), "Chapter 8.5, Interfacing I/O Devices to the Processor, Memory and Operating System", Computer Organization and Design - The Hardware/Software Interface, Third Edition, Morgan Kaufmann, pp. 588–596, ISBN 1-55860-604-1
- 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". http://www.artima.com/index.jsp: artima developer. Retrieved 2011-08-03. "Once you depend on interfaces only, you're decoupled from the implementation. That means the implementation can vary, and that's 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. ..."
- "What Is an Interface". The Java Tutorials. Oracle. Retrieved 2012-05-01.
- "Interfaces". The Java Tutorials. Oracle. Retrieved 2012-05-01.
- "Performance improvement techniques in Serialization". http://www.precisejava.com/: Precise Java. Retrieved 2011-08-04. "We will talk initially about Serializable interface. This is a marker interface and does not have any methods."
- Mössenböck, Hanspeter (2002-03-25). "Advanced C#: Interfaces: Syntax". http://ssw.jku.at/Teaching/Lectures/CSharp/Tutorial/: Institut für Systemsoftware, Johannes Kepler Universität Linz, Fachbereich Informatik. p. 17. Retrieved 2011-08-04.
- Gamma; Helm; Johnson; Vlissides (1995). Design Patterns: Elements of Reusable Object-Oriented Software. Addison Wesley. pp. 17–18.