Editing Interface (computing) (section)

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