Topic: separate a module's interface specification from its implementation

topics > computer science > programming > Group: program module

type declaration

abstract data type
abstraction in programming language
declarative vs. procedural representation
design for change
program module as encapsulation
good requirement specifications
handling complexity
identifying program modules
importance of information hiding for requirement specification
information hiding
interface between program modules
localized understanding
names independent of objects
opaque and partially-opaque data types
operating system kernel
parameter passing by message
sensitivity of software to change
software components
variable as function that accesses an object's value


The most important technique for information hiding is separating the use of something (its interface) from its implementation. Parnas coined the term. (Topic: abstract data type) gives an abstract definition of an interface which has multiple implementations. Message-passing interfaces do a good job at separating the two. (cbb 12/89)
Subtopic: mathematical semantics up

Quote: separate mathematical semantics from the operational semantics; define imperative and dynamic features as change-of-state functions on machine states [»straC1_1974]

Subtopic: decomposition up

Quote: use divide and conquer to handle complexity [»stroB_1991]
Quote: simplify a problem by splitting it into two
Quote: every specification is an implementation of a higher level specification

Subtopic: substitutivity up

Quote: a module can replace another if it implements the same abstraction; without changing other modules
Quote: every class should support at least two significantly different implementations; otherwise the class is an implementation in disguise [»stroB_1991]
Quote: schemes can have the same name if they are different implementations of the same abstraction; need mechanism to pick the best one [»mitcJG_1977]
Quote: changing an array signature to one for sparse arrays is either exactly equivalent or type-incorrect [»demeA3_1979]
Quote: dependency specification better than dependency graph; no transitivity problem, allows polymorphism, supports pre- and post-conditions, enables substitutivity [»jackD10_2002]

Subtopic: integration up

Quote: a programming language should assist with the harmonious integration of separately developed modules; enforce conventions and disciplines [»hoarCA_1974]
Quote: names in a Larch interface specification tie together traits in the Shared language and programs in the programming language [»guttJV9_1985]

Subtopic: abstraction up

Quote: object orientation is encapsulation + abstraction + polymorphism; groups object state and operations with information hiding [»nicoJR6_1993]
Quote: a standard stream package for Modula-3; illustrates partially opaque types and the isolation of unsafe code; based on Topaz [»browMR_1991]
Quote: a software engineer should understand a module's responsibilities without understanding its internal design; should easily identify relevant modules without looking at their components [»parnDL3_1985]
Quote: for information hiding, describe module structure by the roles played, the secrets held, or the facilities provided [»parnDL3_1985]
Quote: a module specification tells you how to use the module and what it must do

Subtopic: policy vs. mechanism up

Quote: C-- separates policy from mechanism; enough hooks to allow a front-end system to implement a high-level run-time service; e.g., garbage collection [»joneSP9_1999]

Subtopic: dependency up

Quote: the connections between parts of programs are the assumptions that the parts make about each other; these connections limit change and make proof difficult [»parnDL_1978]

Subtopic: separate generation from selection up

Quote: lazy evaluation separates the construction of possible answers from the selection of appropriate answers; e.g., Newton-Raphson [»hughJ_1984]

Subtopic: construction, behaviour, and specification up

Quote: describe software by its construction, behaviour, and specification; the behavioural description should match the behavioural specification [»hoffDM_2001]
Quote: a Japanese computer, the TAC, used the same order codes and subroutine library as the EDSAC; only source was this book [»wilkMV_1951]
Quote: can simulate the EDSAC and its subroutine library from the book [»wilkMV_1951]

Subtopic: implementation independent of use/type up

Quote: a type separates the incidental details about the implementation of an object from the essential properties for using an object [»stroB_1991]
Quote: the programmer of a module should not make assumptions about its use; use private storage and treat parameters with suspicion [»morrJH10_1973]
Quote: higher-order-software algorithms never have knowledge of their users [»hamiM3_1976]
Quote: the type of an object is its external interface, while the class of an object is its implementation
Quote: you do not want to look at source code even if it is readily available
Quote: a module or class separates a program into an implementation and an interface
Quote: the major problem with procedural programs is the uncontrolled distribution of information [»creeC11_1997]
Quote: with object-orientation, "date" is an abstraction. Changing its representation only effects the date module
Quote: domain of interaction is independent of the domain of implementation and the subject domain [»winoT7_1979]
Quote: proper names isolate the referring function from the describing function of language

Subtopic: interface separate from implementation, separate development up

Quote: a Limbo program can load different implementations of a module; e.g., load a GIF implementation of an image file [»dorwSM1_1997]
Quote: classes (i.e., data abstractions) define the behavior of objects in an object-oriented database; can change implementation without changing use classes which use the method [»smitKE10_1987]
Quote: good interfaces allow low-level details to change without effecting the higher levels [»rossDT_1970]
Quote: a module should hide a design decision instead of dividing a program into major steps; information hiding [»parnDL12_1972]
Quote: software interfaces have a longer lifetime than programming languages and implementations [»cookRP11_1986]
Quote: define module interfaces as type-specifications before coding; allows independent development [»tichWF9_1979]
Quote: a module interface specification is a formal description of each module as a black box; allows independent development [»parnDL2_1986]
Quote: if interface is separate from implementation can make minor changes safely [»donaJ7_1985a]
Quote: coding the pieces referenced by a GP part can be delegated to different programmers [»randS_1957]
Quote: Alphard's specification sections are the user's sole source of information about a form [»wulfWA6_1976]
Quote: most Ada declarations can be broken into interface and implementation; e.g., declare a constant without giving its value [»maclBJ_1987]
Quote: a programming system needs descriptive structures to maintain 'world views'; independent of implementation [»winoT7_1979]
Quote: representation abstraction separates logical definition from physical implementation; hides information about a module [»taivA4_1993]
Quote: separation of interface and implementation is very important for Cedar
Quote: a deferred Eiffel class specifies an object's behavior with assertions but does not provide a full implementation [»meyeB9_1990]
Quote: the short or abstract form of an Eiffel class gives its interface and assertions without implementation details [»meyeB9_1990]
Quote: both object-oriented and process paradigms based on message passing with clear separation between interface and implementation
Quote: in process paradigm, the type of an interface is independent of its implementation [»stroR10_1986]
Quote: Java does not separate the public class interface from its implementation [»alexRT1_2000]
Quote: an executable object should be distinct from its source text [»kentW_1978]

Subtopic: naming independent of use up

Quote: names are too rich in meaning to waste on talking to computers; Subtext frees names from syntax [»edwaJ10_2005]

Subtopic: representation vs. presentation up

Quote: Smalltalk's Model-View-Controller is a design pattern that separates representation from presentation

Subtopic: contract vs. implementation up

Quote: use abstract classes to decouple contract from implementation; use interfaces to define invariant contracts [»cwalK_2006]

Subtopic: no dependence on details, representation, implementation up

Quote: no component of a complex system should depend on the internal details of another component [»ingaDH8_1981a]
Quote: a program should only specify an object's behavior; not its representation [»ingaDH8_1981a]
Quote: a specification should only concern features of the problem and not features of possible solutions [»meyeB1_1985]
Quote: a module should hide a design decision instead of dividing a program into major steps; information hiding [»parnDL12_1972]
Quote: if one module depends on the implementation details of another module, it may need changing when the other changes
Quote: if a module accesses another object's representation, independent replacement is impossible
Quote: an abstract command specifies behavior without specifying an implementation [»hoarCA8_1986]
Quote: objects should be known via formally specified operations rather than by implementation; i.e., by abstract data type [»meyeB9_1990]
Quote: a module's interface or definition should not reveal its inner workings
Quote: a generalized component should be seen as an operation of an abstract machine; internals are inaccessible [»jackMA_1975]
Quote: use a GP routine by working from the routine's description [»randS_1957]
QuoteRef: guttJV12_1974 ;;51 (procedure specification-- how to construct solution) and (descriptive specification-- description of solution)

Subtopic: no direct access to data, abstract data type up

Quote: a protected interface should contain functions, types, and constants only; otherwise programmers will mess with protected data and cause maintenance problems
Quote: use private storage to maintain the integrity of a data structure
Quote: abstract data types are important; provide access to a type's values through constants and functions; no access to implementation; like a primitive type [»brucKB3_1996]
Quote: datatype has nothing to do with representation; e.g., a complex value is not an ordered pair, and an array is not a contiguous block of values [»meekB9_1994]
Quote: restrict data structures to a module; all other modules must call access programs [»parnDL3_1985]

Subtopic: inheritance up

Quote: use inheritance to isolate users from changes in the implementations of derived classes; e.g., use 'ival_box' to prompt user for an integer value [»koenA12_1995]
Quote: separate inheritance of behavior (behaves-like) from inheritance of representation (subsumes)

Subtopic: data description up

QuoteRef: leonAJ11_1971 ;; Separating logical structure of data file from physical structure
Quote: description files for external objects allow separate compilation and strong type checking [»hansDR11_1979]
Quote: include boolean, state, dates, times, rationals, and complex numbers as primitive datatypes; avoids representational assumptions [»meekB9_1994]

Subtopic: reference test up

Quote: provide reference tests for abstractions; confirm that users implement the contract [»cwalK_2006]

Subtopic: limited encapsulation up

Quote: be careful of making members virtual; they cause subtle and complex observable behaviors and subclass interactions [»cwalK_2006]
Quote: most object-oriented languages allow subclasses to use implementation details of a superclass; limited encapsulation [»liskB_1996]
Quote: a Java stack inherits its vector operations; it should hide the representation [»alexRT1_2000]
Quote: disallow observational exposure of a read-only representation; makes the representation part of the abstract interface and allows concurrency errors [»boylJ7_2005]

Subtopic: problems of representation up

Quote: the original definition of FORTRAN arrays specified a memory layout; caused trauma when later changed the layout

Subtopic: problem of communication up

Quote: for both people and programs separating implementation from interface is easy; the hard part is organizing effective communication between the different sides of the interface [»stroB_1991]

Subtopic: problem of multi-level information up

Quote: high-level run-time services need to inspect and modify the state of a suspended program; e.g., garbage collector and live pointers, exception handler and call stack [»joneSP9_1999]
Quote: high-level run-time services combine information that only the front end has (variables on the heap, which exception handlers in scope), with information that only the back end has (live variables, program-counter values, how to unwind stacks)

Related Topics up

Group: type declaration   (5 topics, 110 quotes)

Topic: abstract data type (64 items)
Topic: abstraction in programming language (47 items)
Topic: declarative vs. procedural representation (54 items)
Topic: design for change (76 items)
Topic: program module as encapsulation (28 items)
Topic: good requirement specifications (36 items)
Topic: handling complexity (60 items)
Topic: identifying program modules (26 items)
Topic: importance of information hiding for requirement specification (23 items)
Topic: information hiding (50 items)
Topic: interface between program modules (55 items)
Topic: localized understanding (43 items)
Topic: names independent of objects (34 items)
Topic: opaque and partially-opaque data types (14 items)
Topic: operating system kernel (67 items)
Topic: parameter passing by message (31 items)
Topic: sensitivity of software to change (44 items)
Topic: software components (11 items)
Topic: variable as function that accesses an object's value
(21 items)

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