Interface (computing): Difference between revisions

Revision as of 06:21, 29 August 2004

Latest revision as of 22:00, 31 August 2025

(803 intermediate revisions by more than 100 users not shown)

Line 1:

{{Short description|Shared boundary between elements of a computing system}}

An '''interface''' is a specification that exists between software components that specifies a selected means of interaction, by means of properties of other software modules, which [[abstraction|abstract]] and [[Information hiding|encapsulate]] their data.

In computing, an '''interface''' is a shared boundary across which two or more separate components of a computer system exchange information. The exchange can be between [[software]], [[computer hardware]], [[peripheral|peripheral devices]], [[User interface|humans]], and combinations of these.<ref name="HookwayInterface14">{{cite book |url=https://books.google.com/books?id=BQM_AwAAQBAJ |chapter=Chapter 1: The Subject of the Interface |title=Interface |author=Hookway, B. |publisher=MIT Press |pages=1–58 |year=2014 |isbn=9780262525503}}</ref> 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.<ref>{{cite encyclopedia

== Interfaces in practice ==

| year = 2000

An interface defines the means of interaction between software components - this includes [[constant]]s, [[data type]]s, [[procedure]]s, and [[method signature]]s. In some instances, it may be useful to define [[variable]]s as part of the interface. It often also specifies the functionality of those procedures and methods, either by [[comment]]s or (in some experimental languages) by formal logical assertions.

| title = IEEE 100 - The Authoritative Dictionary Of IEEE Standards Terms

| publisher = IEEE Press

| ___location = NYC, NY, USA

| isbn = 9780738126012

| pages = 574–575}}</ref>

== Hardware interfaces ==

The interface of a software module <math>A</math> 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 <math>B</math> (which can be referred to as a ''client'' to ''A'') that interacts with <math>A</math> is forced to do so ''only'' through the interface. One practical advantage of this arrangement is that replacing the implementation of <math>A</math> by another one that meets the same specifications of the interface should not cause <math>B</math> to fail &mdash; as long its use of <math>A</math> complies with the specifications of the interface (See also [[Liskov substitution principle]]).

[[File:RJ-45 Ethernet socket on Lenovo T410 Laptop.jpg|thumb|upright=1.4|Hardware interfaces of a [[laptop]] computer: [[Ethernet]] network socket (center), to the left a part of the [[Video Graphics Array|VGA]] port, to the right (upper) a [[display port]] socket, to the right (lower) a [[Universal Serial Bus|USB]]-A socket.]]

{{Main article|Hardware interface}}

Hardware interfaces exist in many components, such as the various [[Bus (computing)|buses]], [[Computer data storage|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).<ref name="87Blaauw">

{{Citation

| last1 = Blaauw

| first1 = Gerritt A.

| last2 = Brooks, Jr.

| first2 = Frederick P.

| title = Computer Architecture-Concepts and Evolution

| publisher = Addison-Wesley

| year = 1997

| chapter = Chapter 8.6, Device Interfaces

| pages = 489–493

| isbn = 0-201-10557-8}}

See also:

{{Citation

| last1 = Patterson

| first1 = David A.

| last2 = Hennessey

| first2 = John L.

| title = Computer Organization and Design - The Hardware/Software Interface, Third Edition

| publisher = Morgan Kaufmann

| year = 2005

| chapter = Chapter 8.5, Interfacing I/O Devices to the Processor, Memory and Operating System

| pages = [https://archive.org/details/isbn_9781558606043/page/588 588–596]

| isbn = 1-55860-604-1

| url-access = registration

| url = https://archive.org/details/isbn_9781558606043/page/588

}}

</ref> 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.<ref name="87Blaauw" /> Hardware interfaces can be [[Parallel communication|parallel]] with several electrical connections carrying parts of the data simultaneously or [[Serial communication|serial]] where data are sent one [[bit]] at a time.<ref name="GovindarajaluIBM08">{{cite book |chapter-url=https://books.google.com/books?id=Hyl8SA1eHzIC&pg=PA142 |chapter=3.15 Peripheral Interfaces and Controllers - OG |title=IBM PC And Clones: Hardware, Troubleshooting And Maintenance |author=Govindarajalu, B. |publisher=Tata McGraw-Hill Publishing Co. Ltd |pages=142–144 |year=2008 |isbn=9780070483118 |access-date=15 June 2018}}</ref>

== Uses ofSoftware interfaces ==

{{See also|Application binary interface|Application programming interface}}

The concept of interface is the cornerstone of [[modular (programming)|modular]] programming, a forerunner and a standard ingredient of [[object-oriented programming]]. In object-oriented programming, an object's interface consists of a set of methods that the object will typically respond to. Note that the object does not make its instance variables a part of its interface - these are typically accessed by means of [[accessor method]]s.

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. [[application software|Application]]s or [[Computer program|program]]s running on the operating system may need to interact via data [[Stream (computing)|streams]], filters, and pipelines.<ref name="BuyyaMastering13">{{cite book |url=https://books.google.com/books?id=VSDZAgAAQBAJ&pg=SA2-PA13 |title=Mastering Cloud Computing |author=Buyya, R. |publisher=Tata McGraw-Hill Education |page=2.13 |year=2013 |isbn=9781259029950}}</ref> In [[Object-oriented programming|object oriented programs]], objects within an application may need to interact via [[Method (computer science)|methods]].<ref name="PooObject08">{{cite book |chapter=Chapter 2: Object, Class, Message and Method |title=Object-Oriented Programming and Java |url=https://archive.org/details/springer_10.1007-978-1-84628-963-7 |author1=Poo, D. |author2=Kiong, D. |author3=Ashok, S. |publisher=Springer-Verlag |pages=7–15 |year=2008 |isbn=9781846289637}}</ref>

Some object-oriented programming languages mandate that the interface to the object be specified to the compiler separately from the implementation of that object, whilst others relax the requirement. For example, a class in a programming languages such as [[Objective-C]] consists of its interface, specified in a header file, and the implementation in the source file. Because of the [[dynamic typing|dynamically typed]] nature of Objective-C, one can send messages to any object, and the interface to the class becomes important as it specifies the methods the class responds to.

=== In practice ===

Interfaces were historically derived from the [[header file]]s of the [[C programming language]] by restricting their syntactic context and contents, and making them a part of the language semantics (as opposed to a mere preprocessor feature).

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.<ref>

{{cite web

|access-date = 2011-08-03

|author = Bill Venners

|date = 2005-06-06

|website= artima developer

|title = Leading-Edge Java: Design Principles from Design Patterns: Program to an interface, not an implementation - A Conversation with Erich Gamma, Part III

|quote = 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. ...

|url = http://www.artima.com/lejava/articles/designprinciples.html

|url-status = live

|archive-url = https://web.archive.org/web/20110805191904/http://www.artima.com/lejava/articles/designprinciples.html

|archive-date = 2011-08-05

}}

</ref> 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|date=June 2018}}

Interfaces between software components can provide [[constant (computer science)|constant]]s, [[data type]]s, types of [[subroutine|procedure]]s, [[exception handling|exception]] specifications, and [[method signature]]s. Sometimes, public [[Variable (programming)|variables]] are also defined as part of an interface.<ref name="PattersonComputer04">{{cite book |title=Computer Organization and Design: The Hardware/Software Interface |author1=Patterson, D.A. |author2=Hennessy, J.L. |date=7 August 2004 |publisher=Elsevier |edition=3rd |page=656 |isbn=9780080502571}}</ref>

The [[Java programming language]] takes a different approach to the concept of the interface normally existing in other [[object-oriented programming]] languages (ie., that the interface specified is the interface to the class), in that an interface specifies a set of methods which implement some specific functionality, common to a set of classes. See [[protocol (object-oriented programming)]].

The interface of a software module ''A'' is deliberately defined separately from the [[Implementation (computer science)|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 (computing)|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 [[Separation of concerns|is only concerned]] with the specifications of the interface. (See also [[Liskov substitution principle]].){{citation needed|date=June 2018}}

Certain programming languages have different methodologies for allowing the construction of interfaces. In general, any programming language can implement an interface, but the following [[programming language]]s provide specific interface ''constructs'' in the programming language of some kind:

* [[Mesa programming language|Mesa]] ([[Xerox PARC]], ca. [[1978]])

=== In object-oriented languages ===

* [[Modula programming language|Modula]] ([[Niklaus Wirth]], [[ETH Zurich]], [[1980s]])

{{Main article|Interface (object-oriented programming)|Concept (generic programming)}}

* [[Modula-2]] ([[Xerox PARC]], ca. [[1983]])

In some [[Object-oriented programming|object-oriented]] languages, especially those without full [[multiple inheritance]], the term ''interface'' is used to define an [[Abstract data type|abstract type]] that acts as an [[abstraction]] of a [[Class (computer science)|class]]. It contains no data, but defines behaviours as [[Method (computer science)|method]] signatures. A [[class (computer science)|class]] having code and data for all the methods corresponding to that interface and declaring so is said to ''implement'' that interface.<ref>{{cite web|url=http://docs.oracle.com/javase/tutorial/java/concepts/interface.html|title=What Is an Interface|work=The Java Tutorials|publisher=Oracle|access-date=2012-05-01|url-status=live|archive-url=https://web.archive.org/web/20120412093619/http://docs.oracle.com/javase/tutorial/java/concepts/interface.html|archive-date=2012-04-12}}</ref> Furthermore, even in single-inheritance-languages, one can implement multiple interfaces, and hence can ''be'' of different types at the same time.<ref>{{cite web|url=http://docs.oracle.com/javase/tutorial/java/IandI/createinterface.html|title=Interfaces|work=The Java Tutorials|publisher=Oracle|access-date=2012-05-01|url-status=live|archive-url=https://web.archive.org/web/20120526080117/http://docs.oracle.com/javase/tutorial/java/IandI/createinterface.html|archive-date=2012-05-26}}</ref>

* [[Oberon programming language|Oberon]] ([[Niklaus Wirth]], [[ETH Zurich]], [[1980s]])

* [[Modula-3 programming language|Modula-3]] ([[Digital Equipment Corporation|DEC]] [[DEC Systems Research Center|SRC]], [[1980s]])

An interface is thus a [[data type|type]] definition; anywhere an object can be exchanged (for example, in a [[function (computer science)|function]] or [[method (computer science)|method]] call) the ''type'' of the object to be exchanged can be defined in terms of one of its implemented ''interface''s or base-classes rather than specifying the specific [[Class (computer science)|class]]. This approach means that any class that implements that interface can be used.{{citation needed|date=June 2018}} For example, a [[Skeleton (computer programming)|dummy implementation]] may be used to allow development to progress before the final implementation is available. In another case, a [[Test-driven development#Fakes, mocks and integration tests|fake or mock]] implementation may be substituted during testing. Such [[Method stub|stub]] implementations are replaced by real code later in the development process.

* [[Java programming language|Java]]

* [[C_sharp|C#]] (included in [[.NET Messenger Service|Microsoft DotNet]]).

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|date=June 2018}} An interface called "<code>[[Stack (data structure)|Stack]]</code>" might define two methods: <code>push()</code> and <code>pop()</code>. It can be implemented in different ways, for example, <code>FastStack</code> and <code>GenericStack</code>—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.

* [[Objective-C]]

* [[Python_programming_language]]

Though interfaces can contain many methods, they may contain only one or even none at all. For example, the [[Java (programming language)|Java]] language defines the interface {{Java|Readable}} that has the single {{Java|read()}} method; various implementations are used for different purposes, including {{Java|BufferedReader}}, {{Java|FileReader}}, {{Java|InputStreamReader}}, {{Java|PipedReader}}, and {{Java|StringReader}}. [[Marker interface pattern|Marker interfaces]] like {{Java|Serializable}} contain no methods at all and serve to provide run-time information to generic processing using [[Reflection (computer programming)|Reflection]].<ref>

{{cite web

|access-date = 2011-08-04

|publisher = Precise Java

|title = Performance improvement techniques in Serialization

|quote = We will talk initially about Serializable interface. This is a marker interface and does not have any methods.

|url = http://www.precisejava.com/javaperf/j2se/Serialization.htm

|url-status = live

|archive-url = https://web.archive.org/web/20110824150046/http://www.precisejava.com/javaperf/j2se/Serialization.htm

|archive-date = 2011-08-24}}</ref>

=== 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.<ref>{{cite book

| last1 = Gamma

| last2 = Helm

| last3 = Johnson

| last4 = Vlissides

| year = 1995

| title = Design Patterns: Elements of Reusable Object-Oriented Software

| url = https://archive.org/details/designpatternsel00gamm

| url-access = registration

| publisher = Addison Wesley

| pages = [https://archive.org/details/designpatternsel00gamm/page/17 17–18]| isbn = 9780201633610

}}</ref>

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 ==

{{Main article|User interface}}

A '''user interface''' is a point of interaction between a computer and humans; it includes any number of [[Modality (human–computer interaction)|modalities]] of [[human-computer interaction|interaction]] (such as graphics, sound, position, movement, etc.) where data is transferred between the user and the computer system.

== See also ==

* [[Abstraction inversion]]

* [[Application binary interface]]

* [[Application programming interface]]

* [[Business Interoperability Interface]]

* [[Computer bus]]

* [[Coupling (computer programming)]]

* [[Hard disk drive interface]]

* [[Implementation (computer science)]]

* [[Implementation inheritance]]

* [[Interoperability]]

* [[Inheritance semantics]]

* [[Modular programming]]

* [[Software componentry]]

* [[Virtual inheritance]]

== References ==

{{Reflist}}

{{Authority control}}

{{DEFAULTSORT:Interface (Computing)}}

[[Category:Interfaces| ]]

[[Category:Object-oriented programming]]

[[Category:Programming constructs]]