User:Tom94022/Interface (computer science)
In the field of computer science, an interface refers to a point of interaction with other components, and is applicable at the level of both [[|Computer hardware|hardware]] and software. This allows a component, whether a piece of hardware such as a graphics card or a piece of software such as an internet browser, to function independently while using interfaces to communicate with other components via an input/output system and an associated protocol.
In addition to hardware and software interfaces, a computing interface may refer to the means of communication between the computer and the user by means of peripheral devices such a monitor or a keyboard, an interface with the internet via Internet Protocol, and any other point of communication involving a computer.
Software Interfaces
editA software interface may refer to a 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
editA piece of software provides access to computer resources (such as memory, CPU, storage, etc.) by its underlying computer system; the availability of these resources to other software can have major ramifications—sometimes disastrous ones—for its functionality and stability. 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.[citation needed]
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 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 experimental languages) by formal logical assertions and preconditions.
The interface of a software module 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 (which can be referred to as a client to A) that interacts with is forced to do so only through the interface. One practical advantage of this arrangement is that replacing the implementation of by another one that meets the same specifications of the interface should not cause to fail—as long as its use of complies with the specifications of the interface (see also Liskov substitution principle).
Software interfaces in object oriented languages
editIn 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 allow later to use the same function exchanging different object types: hence such code turns out to be more generic and reusable.
Usually a method of an interface cannot be used directly, but there must be a class implementing that object to be used for the method invocation.
For example, one can define a interface called Stack that has two methods push()
and 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 slower 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.
In its purest form an interface (like in the Java language)) must include only method definitions and constant values that make up part of the static interface of a type. Some languages (like C#) also permit the definition to include properties owned by the object, which are treated as methods with syntactic sugar.
Programming against software interfaces
editThe use of interface allows to implement a programming style called programming against interfaces. The idea behind this is to base the logic one develops on the sole interface definition of the objects one uses and do not make the code depend on the internal details. This allows 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 limit one can introduce the inversion of control which means leaving the context to inject the code with the specific implementations of the interface that will be used to perform the work.
Hardware Interfaces
editHardware 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)[1] 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. [1].
See also
editReferences
edit- ^ a b Blaauw, Gerritt A.; Brooks, Jr., Frederick P., "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., "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 Kaufman, pp. 588–596, ISBN 1-55860-604-1