World Library  
Flag as Inappropriate
Email this Article

Interface-based programming

Article Id: WHEBN0009478741
Reproduction Date:

Title: Interface-based programming  
Author: World Heritage Encyclopedia
Language: English
Subject: Interface description language, Object-oriented programming
Collection:
Publisher: World Heritage Encyclopedia
Publication
Date:
 

Interface-based programming

Interface-based programming, also known as interface-based architecture, is an architectural pattern for implementing modular programming at the component level in an object-oriented programming language which does not have a module system. An example of such a language is Java, which (as of 2015), does not have a module system at the level of components. Java has a package system, but Java software components typically consist of multiple Java packages – and in any case, interface programming can provide advantages over merely using Java packages, even if a component only consists of a single Java package.

Interface-based programming defines the application as a collection of components, in which API calls between components may only be made to interfaces wherever possible, not concrete classes. It is necessary to call at least one method on a concrete class to obtain a concrete instantiate of an interface, but after that calls may proceed through interfaces.

This is claimed to increase the modularity of the application and hence its maintainability. However, some caution is warranted – merely splitting an application into arbitrary components communicating via interfaces does not in itself guarantee low coupling or high cohesion, two other attributes that are commonly regarded as key for maintainability.

An interface-based architecture can be used when third parties – or indeed separate teams within the same organisation – develop additional components or plugins for an established system. The codebase of the Eclipse IDE is an example of interface-based programming. Eclipse plugin vendors just have to develop components that satisfy the interface specified by the parent application vendor, the Eclipse Foundation. Indeed, in Eclipse, even the original components such as the Java Development Tools are themselves plugins. This is somewhat like a mobile phone manufacturer specifying a mobile charger interface (pin arrangement, expected direct current voltage, etc.) and both the manufacturer and third parties making their own mobile phone chargers that comply with this standard interface specification.

Software evolution in interface-based programming

The use of interfaces to allow disparate teams to collaborate raises the question of how interface changes happen in interface-based programming. The problem is that if an interface is changed, e.g. by adding a new method, old code written to implement the interface will no longer compile – and in the case of dynamically-loaded or linked plugins, will either fail to load or link, or crash at runtime. There are two basic approaches for dealing with this problem:

  1. a new interface may be developed with additional functionality, which might inherit from the old interface
  2. a software versioning policy such as semantic versioning 2.0 may be communicated to interface implementors, to allow forward-incompatible, or even backward-incompatible, changes in future "major" versions of the platform

Both of these approaches have been used in the Java platform.

Design by contract

The publisher of the interfaces generally promises that they will not change the interface in new "minor" versions of the software, and the implementer, by implementing the interface, implies that they have implemented at least the required parts of the interface without any deviation. An interface can therefore be viewed as a "contractual agreement" – but note that it is not a contract in a legal sense. If this contract is documented more formally as a software specification, this is an example of design by contract. However, design by contract per se does not mandate the use of interfaces for all components.

See also

References

  • C# Interface Based Development
  • Interface Based Development – The Unified Modeling Language (UML)
  • Architecting a large application with interface-based architecture
  • Understanding Interface-based Programming
This article was sourced from Creative Commons Attribution-ShareAlike License; additional terms may apply. World Heritage Encyclopedia content is assembled from numerous content providers, Open Access Publishing, and in compliance with The Fair Access to Science and Technology Research Act (FASTR), Wikimedia Foundation, Inc., Public Library of Science, The Encyclopedia of Life, Open Book Publishers (OBP), PubMed, U.S. National Library of Medicine, National Center for Biotechnology Information, U.S. National Library of Medicine, National Institutes of Health (NIH), U.S. Department of Health & Human Services, and USA.gov, which sources content from all federal, state, local, tribal, and territorial government publication portals (.gov, .mil, .edu). Funding for USA.gov and content contributors is made possible from the U.S. Congress, E-Government Act of 2002.
 
Crowd sourced content that is contributed to World Heritage Encyclopedia is peer reviewed and edited by our editorial staff to ensure quality scholarly research articles.
 
By using this site, you agree to the Terms of Use and Privacy Policy. World Heritage Encyclopedia™ is a registered trademark of the World Public Library Association, a non-profit organization.
 



Copyright © World Library Foundation. All rights reserved. eBooks from World Library are sponsored by the World Library Foundation,
a 501c(4) Member's Support Non-Profit Organization, and is NOT affiliated with any governmental agency or department.