Topic: interface between program modules

topics > computer science > programming > Group: program module

data type
program design
requirement specification

decomposition of a system into levels
deployable module or assembly
program module as encapsulation
functional side effects
global declarations and variables
identifying program modules
import/export lists for defining an interface
information hiding
interface type
local declaration of data
object-oriented classes
opaque and partially-opaque data types
representation data type
restricted use of global variables
security by access functions
sensitivity of software to change
separate a module's interface specification from its implementation
software components
software maintenance by patching
software portability
virtual machine


The interfaces between modules are explicitly stated through export/import parameter lists, and implicitly stated in the assumptions that a module makes of others. Both explicit and implied interfaces place modules into interrelated structures. Decomposed modules should have explicit interfaces separate from module specification. Uniform interfaces and standardization make modules interchangeable between implementations. (cbb 5/80)

The purpose of an interface is to separate use of a module from its implementation. This can simply be names and data types. It can also be typestates, error handling, and read-only variables. Thesa makes the instruction syntax the interface to the instruction's code. This serves the same function without artificially combining instructions into modules. If an instruction assumes a restricted way of using its variables, this would be a failure of the type mechanism. (cbb 1/90)

Subtopic: module interface/API up

Quote: design simple, abstract interfaces between modules, otherwise the table structures must be designed carefully; allows independent development [»parnDL12_1972]
Quote: each Oberon module includes a table of commands giving name and entry address; called by M.P [»wirtN9_1989]
Quote: a programming language should assist with the harmonious integration of separately developed modules; enforce conventions and disciplines [»hoarCA_1974]
Quote: Google co-designed its applications and file system API
Quote: Eiffel's 'short' command documents a class by extracting parameters, documentation, pre- and post-conditions [»meyeB10_1992]
Note: a modern programming language is really a large language and a large API; Thesa separates the language from everything else [»cbb_1990, OK]

Subtopic: interfaces are primary up

Quote: interfaces are the most crucial starting point [»rossDT11_1976]
Quote: interface design is the most important part of system design; should be simple, complete, and allow an efficient implementation [»lampBW10_1983]
Quote: interfaces in Modula-2 worked well: i.e., declarations that reveal the public parts of a module. A module imports the interfaces it uses and exports those it implements [»nelsG_1991]
Quote: Sketchpad can perform basic operations on any drawing part (e.g., display); allows changing the specific details without changing the general parts [»suthIE5_1963]
Quote: Sketchpad includes general functions that are independent of type; e.g., expand an instance of a subpicture; powerful [»suthIE5_1963]

Subtopic: interface specifications up

Quote: in interface specification; the programs should be suspicious [»parnDL_1977]
Quote: module specification languages should be different from module interconnection languages [»dereFL6_1975, OK]
Quote: an interface defines a small programming language of objects and operations; does not need a syntactic definition [»lampBW10_1983]
Quote: a function interface should lead to correct code; avoid multiple returns, error values, and multipurpose functions; allow strong argument validation [»maguS_1993]
Quote: a dependency between modules is an assumption about a module's specification in an environment; a module may have multiple specifications, one per dependency [»jackD10_2002]

Subtopic: interface documentation up

Quote: document the API; write doc comments for exported classes, interfaces, constructors, methods, and fields [»blocJ_2001]

Subtopic: interface vs. implementation up

Quote: garbage collection simplifies interfaces; neither client nor implementation frees allocated references; e.g., Modula-3's required interface for Text [»nelsG_1991]
Quote: an abstract interface provides a service without revealing its implementation [»hoffDM_2001]
Quote: behavior across an boundary is interaction; behavior within a boundary is implementation [»winoT7_1979]
Quote: assembly accessibility allows access from an assembly; i.e., one or more application units with name scoping, class versioning, etc.
Quote: a clear box forces cooperation of lower level black boxes; defines a usage hierarchy and box interfaces [»lingRC5_1993]
Quote: a Limbo program can load different implementations of a module; e.g., load a GIF implementation of an image file [»dorwSM1_1997]

Subtopic: interface as assumptions -- contract up

Quote: an interface is a contract to deliver a certain amount of service and functionality [»lampBW10_1983]
Quote: an abstract interface represents the assumptions provided by a collection of device interfaces; it reveals some, but not all, properties of an actual device [»britKH3_1981]
Quote: use iContract for design-by-contract; easy to use [»jazeJM7_2001]
Quote: connections between modules are their assumptions about each other; generally more than calling sequences [»parnDL8_1971]
Quote: a software unit should have no unidentified side effects; i.e., no hidden assumptions [»belaLA_1979]
QuoteRef: chanRN_1974 ;;10 Measure structure by the assumptions each portion makes on the data objects environment, algorithms

Subtopic: interface as parameters up

Quote: the interface between the parts of X+Y is a single number
Quote: arithmetic expressions are highly efficient because of the extreme narrowness of the interface; a single number stored in a high-speed register [»hoarCA_1974]
Quote: Babbage separated variable cards for the store, from operational cards for the mill; parameterized solutions to mathematical problems [»compHU_1946]

Subtopic: interface vs. include up

Quote: interfaces are better than include files; prevent shortcuts across abstraction boundaries. It is too easy to change the meaning of an include file [»nelsG_1991]
Quote: the C preprocessor expands an include statement into the named file's contents [»ritcDM7_1978c]

Subtopic: typestate as part of interface up

Quote: in NIL, module definitions include typestate transitions for parameters; allowed independent development [»stroRE5_1985]
Quote: NIL's typestate interfaces meant that system testing did not reveal new errors in unit-testing; locality of errors was assured [»stroRE5_1985]

Subtopic: procedure arguments as part of interface up

Quote: procedure arguments increases the flexibility of an interface; e.g., a procedure instead of a mini-language for testing some property [»lampBW10_1983]

Subtopic: interface faults up

Quote: unnecessary functions in a class constrain the system's evolution [»stroB_1991]
Quote: if functions directly read or write members, they can make a class an implementation instead of an abstraction
Quote: idiosyncratic interfaces are not usable for widely reusable components and generic programming; interfaces should be obvious and consistently applied [»dehnJC4_1998]

Subtopic: disk files, I/O streams, global variables as interface up

Quote: in most operating systems, the interface between programs is disk files or pipes
Quote: Oberon's interface between consecutive commands is primarily global variables; efficient and flexible; storage reclamation more difficult [»wirtN9_1989]

Subtopic: dependencies as part of interface up

Quote: a software unit must be 'pluggable', with known loading in its use of other objects [»belaLA_1979]
Quote: with upcalls, need to separate client data from the level's data; the later must be consistent and unlocked before an upcall occurs [»clarDD12_1995]

Subtopic: exceptions as part of interface up

Quote: exception handling for external exceptions should be part of an interface specification [»parnDL_1977]
Quote: the header of a CLU procedure specifies how it can terminate; i.e., its signals and return results [»liskBH11_1979]

Subtopic: cost as part of interface up

Quote: while clients of an interface depend on an efficient implementation; the costs are seldom documented [»lampBW10_1983]
Quote: an interface should be fast; basic operations should execute quickly, otherwise everyone pays for a powerful by slow operation [»lampBW10_1983]

Subtopic: testing an API up

Quote: Roast combines test cases with component API documentation; readable test cases with expected output; e.g., valueCheck for asserts and execMonitor for thrown errors [»hoffD7_2000]
Quote: use examples to test API design; test usability, documentation, usefulness; API validated by its users [»mcleSG5_1998]

Subtopic: limitation of abstract interface up

Quote: need to know a component's mechanisms and the order for calling its operations [»boocG_1999]
Quote: an abstract interface can not capture the essence of a program; due to an unbridgeable semantic gap [»weisM11_1987]
Quote: an interface shouldn't hide power; abstractions should not bury the power of lower abstraction levels [»lampBW10_1983]
Quote: an abstract interface is not a fact; it attempts to bridge a gap between two very different worlds [»weisM11_1987]
Quote: instead of researching abstract interfaces ought to study source code to find out what makes programs easier to reuse [»weisM11_1987]

Related Topics up

Group: data type   (34 topics, 730 quotes)
Group: program design   (13 topics, 454 quotes)
Group: requirement specification   (11 topics, 307 quotes)

Topic: decomposition of a system into levels (49 items)
Topic: deployable module or assembly (12 items)
Topic: program module as encapsulation (28 items)
Topic: functional side effects (11 items)
Topic: global declarations and variables (33 items)
Topic: identifying program modules (26 items)
Topic: import/export lists for defining an interface (20 items)
Topic: information hiding (50 items)
Topic: interface type (50 items)
Topic: local declaration of data (11 items)
Topic: object-oriented classes (67 items)
Topic: opaque and partially-opaque data types (14 items)
Topic: representation data type (21 items)
Topic: restricted use of global variables (22 items)
Topic: security by access functions (10 items)
Topic: sensitivity of software to change (44 items)
Topic: separate a module's interface specification from its implementation (86 items)
Topic: software components (11 items)
Topic: software maintenance by patching (27 items)
Topic: software portability (43 items)
Topic: virtual machine
(13 items)

Updated barberCB 8/05
Copyright © 2002-2008 by C. Bradford Barber. All rights reserved.
Thesa is a trademark of C. Bradford Barber.