Object: In modeling terms, an object is a abstraction of an entity in the problem space, i.e., one object corresponds to one entity. Objects with the same Responsibilities that Abstract similar entities get collected as a Class or in Class sets such as a Class Hierarchy. In common usage, one often hears an Object considered as a specific runtime instance of a Class, but one should remember that the purpose of the Object is to correspond to a specific entity in the problem space and that the Class is our effort to create one definition which covers multiple such specific entities.
Overloading: A polymorphism in which the same name is used for different, but analogous Abstractions. In practice, this means defining multiple instances of a Method with the same name, but with different signatures, i.e., different numbers or types of arguments. In use, the correct Method definition is chosen according to the match between the signature of the call and the signature of the available Overloaded Methods with that name.
Override: When a Subclass provides a matching definition for a method in its Superclass, the method in the Subclass overrides the definition in the Superclass. This Override may either totally replace the definition in the Superclass or the method of the Subclass may invoke the logic of the Superclass as part of its operation.
Package: A collection of closely related and cooperating Classes.
Polymorphism: Can mean several different, but related things. Inclusion or Subtype Polymorphism is defining a Method in a Superclass and then providing different implementations of that Method in various Subclasses. Referencing the Method in the Superclass will call the implementation of the current Subclass instance, thus providing different behaviors for the same Method depending on which Subclass is currently in existence without having to recognize the Type of the Subclass. Overload Polymorphism is provided by Overloading a Method. Operator Overloading, which does not exist in OOABL, is providing alternate, type-specific behaviors for primitive operators such as + and -.
Programming by Contract: See Design by Contract.
Property: An attribute or data Member of a Class. In OOABL these are characterized by having a usage syntax which gives the appearance of public access, but includes internal features to control read-only or write-only access and to provide any desired code to map between the external appearance and the internal implementation.
Realization: A component providing a Concrete Implementation for an Interface.
Responsibility: An obligation to know or do something. A coherent function that a Class performs; sometimes referred to in terms of a “reason to change”. For example, if a given display needs to change, it is likely that it needs to change in terms of format or it needs to change in terms of content, but not both. Thus, format and content are separate Responsibilities.
Signature: The visible characteristics of a Method, i.e., its returned Type and parameters.
Specialization: When one recognizes that an existing class has some different knowledge or behavior in specific rôles, contexts, or states, one can then create a relationship in which the existing class is a parent or Superclass to a set of classes (the Subclasses), each of which implements the knowledge and behavior appropriate to a particular rôle, context, or state. See Generalization and Inheritance. Many authors do not use the word Specialization, but refer to all instances as Generalization.
| Attachment | Size |
|---|---|
| OOVocabulary_20100116.pdf | 75.84 KB |
- Show full page
- Printer-friendly version
- Login or register to post comments
-
- Send to friend

