Group: type inheritance
Topic: abstract data type
Topic: abstract functions
Topic: collection class
Topic: design pattern
Topic: inheritance of properties
Topic: interface type
Topic: object-oriented classes
Topic: object-oriented data types
Topic: object-oriented design
Topic: object-oriented prototypes
Topic: opaque and partially-opaque data types
Topic: optimization of object-oriented programs
Topic: user-defined data type
Topic: value as an object
| |
Subtopic: generic class
Quote: Eiffel's generic classes have type parameters; can restrict a type parameter to descendants of a given class [»meyeB9_1990]
| Subtopic: hierarchical class
Quote: use derived classes to express hierarchical relationships; i.e., commonality between classes
| Subtopic: concrete/value type
Quote: use concrete types for efficiency and abstract types for flexibility; neither are useful for inheritance [»stroB_1991]
| Quote: a concrete type or value type is like an 'int'; it does one thing well and efficiently without inheritance; e.g., 'date' [»koenA12_1995]
| Quote: a concrete type such as 'date' is closely matched to an efficient, complete implementation without dependencies on other classes [»stroB_1991]
| Quote: concrete types do not express commonality of concepts; e.g., a 'set' is not a concrete type because it may be an 'slist' or a 'vector' with different performance characteristics
| Subtopic: interface class
Quote: an interface class specializes the appearance of some service. Need not generate code, e.g., a template for a type-safe list from a list of 'void*' pointers [»stroB_1991]
| Quote: use inline functions to make interface classes affordable; e.g., an inline forwarding function that adjusts the type without generating additional code [»stroB_1991]
| Subtopic: type handle
Quote: CLR objects include vtable pointers for method dispatch and simple type handles [»kennA6_2001]
| Subtopic: fat interface
Quote: a fat interface is a class that provides all functions for a set of concepts, e.g., a universal 'container' class [»stroB_1991]
| Quote: avoid fat interfaces: slow implementation, difficult to prove, weak correspondence between concepts and classes, encourages the use of derivation for implementation convenience
| Quote: the classes in an application framework have fat interfaces that are hardly types in the traditional sense
| Subtopic: node class
Quote: a node class belongs to a type hierarchy. It provides an interface and services. It relies on base classes [»stroB_1991]
| Quote: a node class usually has a non-trivial constructor; unlike abstract types that rarely have constructors
| Subtopic: enumeration class
Quote: declare classes for enumerations and enumeration constants, with objects for enumeration values [»linsC7_1990]
| Subtopic: canonical form
Quote: orthodox canonical form provides default constructor/destructor, copy constructor, and assignment; allows reliable copy and delete of heap memory [»simoAJ10_1998]
| Subtopic: anonymous inner class
Quote: anonymous inner classes implement closures; e.g., makeAdder(n) [»bensBW2_1999]
| Subtopic: exceptions
Quote: the most natural way to describe exceptions is to throw objects and catch classes; a copy of the object thrown is passed to the handler [»koenA_1990]
|
Related Topics
Group: type inheritance (13 topics, 394 quotes)
Topic: abstract data type (64 items)
Topic: abstract functions (11 items)
Topic: collection class (11 items)
Topic: design pattern (17 items)
Topic: inheritance of properties (24 items)
Topic: interface type (50 items)
Topic: object-oriented classes (67 items)
Topic: object-oriented data types (29 items)
Topic: object-oriented design (30 items)
Topic: object-oriented prototypes (39 items)
Topic: opaque and partially-opaque data types (14 items)
Topic: optimization of object-oriented programs (16 items)
Topic: user-defined data type (13 items)
Topic: value as an object (29 items)
|