Topic: program module as encapsulation

topics > computer science > programming > Group: program module

data type
program design

abstract data type
abstraction in programming
aspect-oriented programming
declaration scope
decomposition of a system into levels
design for change
families of programs
identifying program modules
information hiding
interface between program modules
localized understanding
object-oriented classes
programming with a database of modules
separate a module's interface specification from its implementation
software components
software tools
system integration


A difficult, yet important, programming task is to break a problem into independent modules. These independent modules form a structured problem representation. A common decomposition is by hierarchical layers with sub-layers affecting only their parents. Each layer hides a source of indeterminacy from higher levels; i.e., the representation of a layer can be changed independently of other layers. The resulting insensitivity to change is another name for independence. It can be applied per module as well as per layer. This means that modules are interconnected only by reference or uniform data representation.

The content of each module should not effect its use; execution sequences should not effect its behavior; and the interconnections between modules should be flexible. Since module modification must be anticipated, difficult design decisions need to be identified before modules are determined. Effective decomposition needs to be as complete as possible; this implies that the specification tools must handle a large number of small modules. Decomposition should apply at all levels from atomic programming units to major programs or collections of programs. Ideally there is an identifiable module for each individual input or output entity in the real world. (cbb 5/80)

Subtopic: encapsulation as module up

Quote: a programming language needs modularization to encapsulate abstract concepts [»wirtN3_1976]
Quote: independent modules require encapsulation and specification [»liskB_1996]
Quote: design for change by making a system flexible, extensible, and portable. Encapsulate the areas that are likely to change [»stroB_1991]
Quote: an interface should solve only one problem and let client routines do the rest; e.g., a parser calls client-supplied semantic routines [»lampBW10_1983]
Quote: encapsulation reduces the need for information hiding

Subtopic: module as hiding information up

Quote: a module should hide a design decision instead of dividing a program into major steps; information hiding [»parnDL12_1972]
Quote: a module hides a data structure with its internal links, accessing procedures, and modifying procedures [»parnDL12_1972]
Quote: design modules by hiding difficult or likely-to-change design decisions; not flowcharts or processing steps [»parnDL12_1972]
Quote: a module should hide the sequence for processing an item; also character codes and alphabetic ordering

Subtopic: module as well-defined, abstract unit up

Quote: an independent component of a system should appear only once [»ingaDH8_1981a]
Quote: a functionally strong module performs only one generic function, like square root; highly reusable [»joneTC4_1979b]
Quote: write large programs as segments (one page, one entrance and exit); refer to other segments as needed [»millHD_1971_, OK]
QuoteRef: conwME7_1963 ;;396 separable program if collection of modules with one-way, non-looping, discrete, flow of input and output
Quote: divide task-level plans for arms into action chunks with segmentation at interdependencies [»roacJW10_1987]
Quote: CLU uses a database of descriptive units; built incrementally; shows abstractions, parameters, operations, clusters, cross references [»liskBH2_1976, OK]
Quote: should not combine simple functions into one component [»parnDL5_1978]
Quote: a programming language needs modularization to encapsulate abstract concepts [»wirtN3_1976]
Quote: ideally, each class is responsible for the maintenance of all information relating to a single concept. If so, a change in a concept effects one class only
Quote: Jackson sees a system as many individual programs, one for each relevant entity in the real world [»jackMA_1975]
Quote: a module can replace another if it implements the same abstraction; without changing other modules

Subtopic: type vs. module up

Quote: a type defines a set of values while a module groups related declarations; a module exists in exactly one instance [»batesR11_2004]
Quote: Java classes describe a type with its instance variables and a module with its class variables; confuses type with module
Quote: a class method is not a method at all; it is a function, without a receiver [»batesR11_2004]

Subtopic: modules as functions up

Quote: avoid unordered modules, each implementing a function; difficult to integrate with each other; quadratic growth in complexity [»dijkEW2_1971]

Subtopic: problems with encapsulation up

Quote: class inheritance doesn't preserve encapsulation because functions are scattered among classes with many interdependencies [»wyboN4_1990]
Quote: end-to-end argument--implement functions at the endpoints of a communication system; do not implement within the communication system unless needed for efficiency [»saltJH11_1984]
Quote: an interaction object, e.g., filling a form, is implemented by a single component; while a subject domain object clearly cuts across the system [»winoT7_1979]
Quote: modularity decays; in 1989, the change history clearly separated two clusters of modules; by 1996, these clusters had broken down

Related Topics up

Group: data type   (34 topics, 730 quotes)
Group: program design   (13 topics, 454 quotes)

Topic: abstract data type (64 items)
Topic: abstraction in programming (67 items)
Topic: aspect-oriented programming (2 items)
Topic: declaration scope (16 items)
Topic: decomposition of a system into levels (49 items)
Topic: design for change (76 items)
Topic: families of programs (11 items)
Topic: identifying program modules (26 items)
Topic: information hiding (50 items)
Topic: interface between program modules (55 items)
Topic: localized understanding (43 items)
Topic: object-oriented classes (67 items)
Topic: programming with a database of modules (94 items)
Topic: separate a module's interface specification from its implementation (86 items)
Topic: software components (11 items)
Topic: software tools (20 items)
Topic: system integration
(5 items)

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