| 
|
QuoteRef: taivA4_1993
topics >
all references >
ThesaHelp:
references t-z
Group:
object-oriented programming
Topic:
abstract data type
Topic:
object-oriented fields
Topic:
objects as a set of attributes
Topic:
abstract functions
Topic:
unique names
Topic:
object-oriented objects
Topic:
names as rigid designators
Topic:
value as an abstraction
Topic:
abstraction
Topic:
abstraction in programming language
Topic:
referential transparency
Topic:
value as an object
Topic:
functional programming
Topic:
identifying program modules
Topic:
localized understanding
Topic:
abstraction in programming
Topic:
separate a module's interface specification from its implementation
Topic:
information hiding
Topic:
data type as a set of operations
Topic:
data record
Topic:
uniform reference to data
Topic:
primitive data type as memory
Topic:
variable as reference to storage
Reference
Taivalsaari, A., "On the notion of object", Journal of Systems and Software, 21 , 1, pp. 3-16, April 1993. Google
5 ;;Quote: object oriented programming is objects and inheritance; abstract data types are too restrictive
6 ;;Quote: an object has an identity and a set of properties; an Aristotelian view of the world
6 ;;Quote: an object implements an abstract data type with a private, mutable state and public operations on the state
6 ;;Quote: an object is anything that has a unique identifier; e.g., an immutable tag or a memory address
7 ;;Quote: abstractions either have an "eternal" existence (values, concepts) or a temporary, tangible existence (objects)
8 ;;Quote: values are referentially transparent while objects are referentially opaque; i.e., values do not have side effects and identical values may be substituted freely
8 ;;Quote: object-oriented programming is the antithesis of functional programming; i.e., mutable object state vs. immutable, eternal values
8 ;;Quote: abstraction is ignoring the irrelevant aspects of a subject in order to concentrate solely on the relevant aspects
9 ;;Quote: locality of information (modules): a programming system should keep related pieces of behavior and data together
9 ;;Quote: representation abstraction separates logical definition from physical implementation; hides information about a module
9 ;;Quote: data abstraction is the definition of a data type in terms of operations on the data type; a value or state is otherwise inaccessible
11 ;;Quote: storage semantics is more common than value or reference semantics; represent objects by containment or by references, whichever works better
11 ;;Quote: storage semantics in object-oriented languages leads to problems with copying, destruction, and comparison
ThesaHelp: references t-z (309 items)
Group: object-oriented programming (26 topics, 822 quotes)
Topic: abstract data type (64 items)
Topic: object-oriented fields (28 items)
Topic: objects as a set of attributes (39 items)
Topic: abstract functions (11 items)
Topic: unique names (58 items)
Topic: object-oriented objects (39 items)
Topic: names as rigid designators (43 items)
Topic: value as an abstraction (25 items)
Topic: abstraction (62 items)
Topic: abstraction in programming language (47 items)
Topic: referential transparency (26 items)
Topic: value as an object (29 items)
Topic: functional programming (45 items)
Topic: identifying program modules (26 items)
Topic: localized understanding (43 items)
Topic: abstraction in programming (67 items)
Topic: separate a module's interface specification from its implementation (86 items)
Topic: information hiding (50 items)
Topic: data type as a set of operations (38 items)
Topic: data record (57 items)
Topic: uniform reference to data (34 items)
Topic: primitive data type as memory (29 items)
Topic: variable as reference to storage (12 items)