Group:
information
Group:
program design
Topic:
abstract data type
Topic:
importance of information hiding for requirement specification
Topic:
separate a module's interface specification from its implementation
Topic:
abstraction in programming
Topic:
aspect-oriented programming
Topic:
declarative vs. procedural representation
Topic:
decomposition of a system into levels
Topic:
design for change
Topic:
program module as encapsulation
Topic:
handling complexity
Topic:
families of programs
Topic:
identifying program modules
Topic:
interface between program modules
Topic:
local declaration of data
Topic:
localized understanding
Topic:
meaning vs. reference
Topic:
object-oriented design
Topic:
opaque and partially-opaque data types
Topic:
restricted use of global variables
Topic:
reusable programming
Topic:
security by access functions
Topic:
the 'uses' hierarchy for organizing systems
Topic:
virtual machine
| |
Summary
A good programmer makes use of available information. Information should be hidden if its use makes a system difficult to understand and modify. Interfaces simplify a system by dividing the system into regions with clearly defined boundaries. (cbb 12/89)
Subtopic: allow change 
| Quote: change a module's implementation without knowledge of the implementation of other modules and without affecting the behavior of other modules [»parnDL3_1985]
| | Quote: information hiding minimizes the cost of software by estimating the likelihood of change; likely changes should be easily made [»parnDL3_1985]
|
Subtopic: hide information
| 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]
| | Quote: well-structured programs limit the assumptions that parts make about each other
| | Quote: secrets are more important than interfaces or roles; secrets clarify the responsibilities of a module [»parnDL3_1985]
| | Quote: because of multiple disciplines, information hiding occurs naturally in many engineering projects, e.g., transformers; not true for software [»parnDL6_1990]
| | Quote: information hiding: user has everything needed to use a module but nothing more; the implementer has everything to implement a module and nothing more [»maclBJ_1987]
| | Quote: information hiding necessary if designers wish to maintain control over a program's structure [»parnDL8_1971]
| | Quote: higher-order-software algorithms never have knowledge of their users [»hamiM3_1976]
| | Quote: the major problem with procedural programs is the uncontrolled distribution of information [»creeC11_1997]
| | Quote: for information hiding, describe module structure by the roles played, the secrets held, or the facilities provided [»parnDL3_1985]
|
Subtopic: hide decisions
| Quote: a module should hide a design decision instead of dividing a program into major steps; information hiding [»parnDL12_1972]
| | Quote: design modules by hiding difficult or likely-to-change design decisions; not flowcharts or processing steps [»parnDL12_1972]
|
Subtopic: abstract interface
| Quote: an abstract interface provides a service without revealing its implementation [»hoffDM_2001]
| | Quote: Alphard's specification sections are the user's sole source of information about a form [»wulfWA6_1976]
|
Subtopic: hide implementation
| Quote: the A-7E flight software consists of a hardware-hiding module (hardware interfaces), a behavior-hiding module, and a software decision module (performance-related decisions)
| | Quote: an abstract interface provides a service without revealing its implementation [»hoffDM_2001]
| | Quote: a module should hide the sequence for processing an item; also character codes and alphabetic ordering
| | Quote: use routines to reduce complexity by hiding the details [»mccoS7_1998]
| | Quote: routines hide the order in which events occur; e.g., data from user and data from file in either order [»mccoS7_1998]
| | Quote: you do not want to look at source code even if it is readily available
| | Quote: representation abstraction separates logical definition from physical implementation; hides information about a module [»taivA4_1993]
|
Subtopic: objects hide implementation
| Quote: object orientation is encapsulation + abstraction + polymorphism; groups object state and operations with information hiding [»nicoJR6_1993]
| | Quote: categorize methods/functions as command or query; freely use queries while commands hide information [»huntA1_2003]
| | Quote: do not query an object, make a decision, and perform an action (procedural, bug prone) [»huntA1_2003]
| | Quote: tell objects what needs to be done, keep decisions inside objects (object-oriented, encapsulated)
|
Subtopic: limited access to data
| Quote: if restrict access to a data structure then only member functions can modify the data, cause illegal values, and define how to use the data [»stroB_1991]
| | Quote: named relationships hides their representation from the user [»kentW_1978]
| | Quote: in a 'uses' hierarchy, low level operations may assume a data structure, next level may allow similar data structures, and top level doesn't know [»parnDL5_1978]
| | Quote: a module hides a data structure with its internal links, accessing procedures, and modifying procedures [»parnDL12_1972]
| | Quote: restrict data structures to a module; all other modules must call access programs [»parnDL3_1985]
| | Quote: in a good CADES design, each holon manipulates a small subset of data items provided by its parent holon [»pearDJ7_1973]
| | Quote: except for low-level types or math entities, avoid global data, global functions, public data, friends, direct access, type fields, inline functions, void*, pointer arithmetic, C arrays, and casts [»stroB_1991]
| | Quote: MIL uses names of resources to convey or restrict access information between modules [»dereFL6_1975]
|
Subtopic: encapsulation vs. information hiding
| Quote: after each software development step, it must move to another place; avoids hidden information and insures isolation [»mcgoMJ7_1983]
| | Quote: hide interrupts via abstract processors; everything else as cooperating sequential processes [»dijkEW2_1971]
| | Quote: encapsulation reduces the need for information hiding
| | Quote: C++ types and data-hiding efficiently prevent accidental corruption of data. They do not provide secrecy and security [»stroB_1991]
|
Subtopic: full access to information
| Note: information is language and hence public; not private as in object-oriented programming [»cbb_1990, OK]
| | Quote: information hiding conflicts with code reading and other desirable activities [»liskB_1996]
| | Quote: a good programmer makes use of available information
| | Quote: access to source code does not violate information hiding because access is to people, not modules [»weisM11_1987]
| | Quote: a system has uniform closure if every component can access every other component, including their descriptions [»smitDR11_1985]
|
Subtopic: problems with overloading
| Quote: an overloaded or hidden name can cause difficult errors; minimize by avoiding names like 'i' for globals or variables in large functions [»stroB_1991]
|
Subtopic: problems of encapsulation
| Note: access control and visibility tend to be either too limited or too liberal; hard to make them work [»cbb_1990, OK]
| | 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]
| | Quote: class inheritance doesn't preserve encapsulation because functions are scattered among classes with many interdependencies [»wyboN4_1990]
|
Subtopic: problems with information hiding
| Quote: requirement changes often cross-cut information hiding boundaries; should restructure the code, but restructuring is expensive without observable change [»berrDM10_2002]
| | Quote: information hiding can lead to inefficient switching between modules due to subroutine calls; allow inline expansion of module code [»parnDL12_1972]
| Quote: Google co-designed its applications and file system API
|
Related Topics
Group: information (46 topics, 1160 quotes)
Group: program design (13 topics, 454 quotes)
Topic: abstract data type (64 items)
Topic: importance of information hiding for requirement specification (23 items)
Topic: separate a module's interface specification from its implementation (86 items)
Topic: abstraction in programming (67 items)
Topic: aspect-oriented programming (2 items)
Topic: declarative vs. procedural representation (54 items)
Topic: decomposition of a system into levels (49 items)
Topic: design for change (76 items)
Topic: program module as encapsulation (28 items)
Topic: handling complexity (60 items)
Topic: families of programs (11 items)
Topic: identifying program modules (26 items)
Topic: interface between program modules (55 items)
Topic: local declaration of data (11 items)
Topic: localized understanding (43 items)
Topic: meaning vs. reference (49 items)
Topic: object-oriented design (30 items)
Topic: opaque and partially-opaque data types (14 items)
Topic: restricted use of global variables (22 items)
Topic: reusable programming (77 items)
Topic: security by access functions (10 items)
Topic: the 'uses' hierarchy for organizing systems (18 items)
Topic: virtual machine
(13 items)
|
