Group:
data type
Group:
program design
Group:
requirement specification
Topic:
decomposition of a system into levels
Topic:
deployable module or assembly
Topic:
program module as encapsulation
Topic:
functional side effects
Topic:
global declarations and variables
Topic:
identifying program modules
Topic:
import/export lists for defining an interface
Topic:
information hiding
Topic:
interface type
Topic:
local declaration of data
Topic:
object-oriented classes
Topic:
opaque and partially-opaque data types
Topic:
representation data type
Topic:
restricted use of global variables
Topic:
security by access functions
Topic:
sensitivity of software to change
Topic:
separate a module's interface specification from its implementation
Topic:
software components
Topic:
software maintenance by patching
Topic:
software portability
Topic:
virtual machine
| |
Summary
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 
| 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
| 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
| 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
| Quote: document the API; write doc comments for exported classes, interfaces, constructors, methods, and fields [»blocJ_2001]
|
Subtopic: interface vs. implementation
| 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
| 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
| 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
| 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
| 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
| 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
| 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
| 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
| 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
| 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
| 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
| 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
| 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
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)
|
