Object-Oriented Glossary

Like all technical subjects, there is a lot of jargon to learn in the object-oriented approach. There's no escaping it because there are a lot of key, complex topics that need names. The amount of cross-referencing in this page should make it clear how inter-related these terms are! Note that this document only gives basic definitions and the student is strongly advised to research these terms in more depth.

If you'd prefer a printable document, you can get the PDF version here (the two versions should be (more or less) in step).


A|B|C|D|E|F|G|H|I|J|K|L|M|N|O|P|Q|R|S|T|U|V|W|X|Y|Z

Abstract class
A class with one or more abstract methods. C# and Java just call these "abstract methods", but in C++ they are known as "pure virtual methods". Abstract classes cannot be instantiated.
Abstract data type
A mathematical model of a data structure defined in terms of the operations that can be performed on it.
Abstract method
A method signature with no body. An abstract method is a contractual obligation that subclasses must define to provide the required functionality.
Abstraction
  1. The ability to use a class or method without knowing anything about the details of its implementation.
  2. The process of identifying the key common features across a range of specific instances. Those common features provide the basis for defining superclasses.
Activity diagram
A diagram in the UML that models control flow within a process. This is very similar to a traditional flow chart with the addition of notation for concurrency. This is part of the dynamic model.
Actor
A role in the UML used to describe an entity that interacts with a system to produce behaviour. An actor may be a human or another system.
Aggregation
A form of association where the containing object does not own or exclusively control the contained (aggregated) object. In other words, the containing object may share its aggregated objects. (Compare with composition).
Analysis
The investigation of a problem domain to identify the entities, relationships and requirements.
API
An abbreviation of Application Programming Interface.
Application Programming Interface
An abstraction that defines a software component solely in terms of its abstract data types, attributes and operations. An API provides a detail specification of how to access the functionality of a set of software components.
Association
A general, unspecific term indicating that there is some relation between two classes or two objects. See also aggregation and composition.
Attribute
The information stored in a particular instance of a class which makes that object distinct from other instances of the same class.
Base class
The most immediate superclass of a derived class.
Class
The definition of a complex type in object oriented programming. Classes contain attributes to store information specific to their instances and methods to provide the operations that define their behaviour.
Class diagram
A UML diagram that forms part of the static model of a system. It shows the relationships between the classes in the system, and notates the properties and behaviours of those classes. A class diagram may be used for a domain model or a design model.
Class variable
A variable that is defined at the class level. Only one copy of the variable exists and it is shared by all instances of the class. Known as a static variable in Java and C#. This is the opposite of an instance variable.
Cohesion
A desirable property of a class definition whereby all of the attributes and operations of the class are closely related to a well-defined and narrow set of functions.
Collaboration
Two or more objects working together to complete a particular task.
Complex type
A data type constructed from a collection of primitive types and other complex types. This is also known as a composite type. In Java a complex type is defined using arrays and/or the class constructions. In C# and C++ the struct construction is added to these possibilities.
Composition
A form of association where the containing object owns and has exclusive control over the contained (composite) object. It does not share its composed objects. (Compare with aggregation).
Composite type
Another name for complex type.
Construction
The third stage in the unified process where the bulk of the system implementation and testing is completed. Each iteration of this stage should yield a functional beta version of the system.
Coupling
An undesirable property of two or more classes whereby the attributes and operations of one class are dependent on the attributes and operations of the other class in such a way that one class cannot be used without the other.
Data hiding
See encapsulation.
Dependency Inversion Principle
This is an application of abstraction (meaning i) to the design of layered architectures. Rather than having high level modules depend upon the implementation of low level modules, both should depend on abstractions, typically through the use of interfaces to define their interactions.
Derived class
Another name for subclass.
Design
The activity, in a development methodology, that transforms the project requirements into descriptions that can be inputs to the implementation process.
Design model
A model of the relationships between classes and behaviours of the software entities that will be implemented to solve the problem.
Domain model
A model of the problem that identifies the key entities in the domain. It shows the important relationships between the domain entities and the attributes and operations that those entities have. Crucially, a domain model should make no reference to design or implementation considerations.
Dynamic memory allocation
A programming technique where the allocation of memory is delayed until run-time. This means that the precise amount of memory required can be computed will the programming is running. The opposite of static memory allocation.
Dynamic model
This describes how the systems behaves over time. Typically it constructed using a combination of activity diagrams, state diagrams and sequence diagrams.
Dynamic typing
A dynamically typed language allows data of any type to be stored in any variable. The "type" of the variable changes dynamically to reflect what it is storing at any given moment at run-time. The definition of the types themselves may also change dynamically. JavaScript is a dynamically typed language. Contrast with statically typed.
Elaboration
The second stage in the unified process where the bulk of the use cases are defined, the core of the system architecture is developed. This process is achieved through several iterations.
Encapsulation
  1. The technique of combining the data and the functions responsible for operating on that data into a single object.
  2. The technique of controlling access to the attributes and operations of an object by specifying visibility modifiers.
Extension
Another name for subclassing. If class B is a subclass of class A, then B extends A.
Formal parameter
The declaration of a parameter (including its type) that appears in the definition of a method or function. Part of the method signature. The formal parameters of a method define the data that the method expects and requires to complete its task.
Function
A more general name for a method. A section of named code that is intended to perform a single purpose. The definition of a function is such that it should return a value as a result of the computation. A method may, or may not, return a value.
Guard condition
  1. (UML) a Boolean expression that controls whether a specific set of actions in a sequence diagram will execute.
  2. (general) a Boolean expression that determines whether the data passed into a function is valid, controlling whether the function should continue.
Implementation
A distinct phase of an iteration of the Unified Process where code is being written and tested.
Inception
The first stage in the unified process. The business case for the project is established, key risks are identified, and the core use cases are defined.
Inheritance
The mechanism by which a subclass takes on the attributes and operations of its superclass.
Inner class
A class defined within the scope of another class. The visibility of the inner class may be any of the standard levels: private, protected, package or public. However, design considerations dictate that only private or protected are likely to be used.
Instance
An object of a specific type, where the type is specified by a class. The object is said to be an instance of the class.
Instance variable
A variable that exists at the object level. Each object gets its own copy of the variable, and each object can therefore assign a different value to the variable. The opposite of a class variable.
Instantiation
The process of creating an instance from a class.
Interaction constraint
Another name for a guard condition (UML).
Interface
A specification of method signatures that a class must provide if it is to be considered as implementing the interface. Like classes, an interface defines a type. A class that implements an interface is a subtype of the type defined by the interface.
Interface Segregation Principle
The principle that interfaces should be kept as small as possible, only defining methods that are specific to their role. This allows programs to maintain low coupling.
Liskov Substitution Principle
A principle formulated by Barbara Liskov and Jannette Wing, which says that: if S is a subtype of T, then objects of type T may be replaced by objects of type S without altering any of the key properties of the program.
Member
A generic term covering both attributes and operations.
Method
The name usually given to procedures and functions in OOP. A method is a function or procedure that is a member of an object or class and which defines an operation for that object or class.
Method signature
The information that uniquely identifies a method. This is composed of the name of the method, and the order and types of the formal parameters. Note that in most languages, the return type is not part of the signature.
Namespace
Another term for package, used in C# and C++.
Object
A specific instance of a class. All objects of a specific class will share the same operations, but will have their own values for the attributes.
Object diagram
A diagram in the UML that shows the attribute values of specific objects and the relationships between objects. An object diagram is part of the static model of a system.
Open/Closed Principle
A class should be open for extension, but closed for modification. This has a number of interpretations. One view would be that it is a way of saying that behaviours are developed through inheritance, without the need to modify the base class.
Operation
A unit of functionality in a class that defines some of the behaviour that a class can provide. A operation is usually implemented as a method.
Overload
A technique where many different methods are defined with the same name, but with different formal parameters. Thus, a class could define an add method that added strings to its store and another method, also called add, that added integers to its store. This technique can lead to confusing API designs and should be used sparingly.
Override
A technique where a subclass replaces a method in one of its superclasses with its own version.
Package
A large scale unit of organization in an OOP project that groups together a number of related classes. A large project will consist of several packages, each defining a subset of the complete system’s functionality.
Package visibility
A level of visibility modification that ensures that only objects and classes in the same package can access the attributes and operations of the relevant object.
Polymorphism
  1. The principle that allows an object of a specific type to also be treated as an instance of any of its supertypes.
  2. The principle that allows a derived class to override the methods of its superclass with its own definitions.
Postcondition
One or more conditions that are guaranteed to be true on the completion of a method’s execution, assuming that its preconditions are true.
Precondition
One or more conditions that need to be true for a method call to be considered valid. Typically preconditions express constraints on the input data to the method, or constraints on the state of the method’s object. If the preconditions are true, the method should function correctly. If the preconditions are false, there are no guarantees about the result of calling the method. These are typically described by guard conditions in UML models.
Primitive type
A basic data type, with support for manipulating it built in to the language. A primitive type would usually be a value type.
Private
A visibility modifier which ensures that private attributes, methods and inner classes are only available within the class in which they are defined.
Procedure
A named section of code that performs a specific operation. A procedure would not be expected to return a value. Compare with function and method.
Property
Another word for attribute.
Protected
A visibility modifier which ensures that protected members are only visible with the class in which they are defined and subclasses of that class. Note that the Java implementation of this visibility modifier violates this definition.
Public
A visibility modifier which ensures that public members and classes are visible anywhere in the system.
Reusability
A property of well-designed software components that means they can be used again in a different project with little or no modification.
Requirements
The statement of what a software system needs to achieve in order to be considered a success by the project stakeholders. In object-oriented analysis and design, most requirements are usually captured via use cases.
Sequence diagram
A UML diagram that shows the sequence of interactions between two or more entities over time. The entities are represented as parallel vertical lines, with time running from top to bottom. The interaction is shown as messages exchanged between the entities. This is part of the dynamic model of a system.
Single Responsibility Principle
(SRP) The idea that a class should only have responsibility for a single part of a system's functionality. That responsibility should be encapsulated by the class. This facilitates high cohesion in a design.
SOLID
A set of design principles that should be applied in object-oriented programming:
  1. Single responsibility principle
  2. Open/closed principle
  3. Liskov substitution princile
  4. Interface segregation principle
  5. Dependency inversion principle
Specialization
Another way of describing subclassing. If B is a subclass of A, then B is a specialization of A.
State diagram
A UML diagram that shows the behaviour of a system in terms of event-driven transitions from one state to another. These are part of the dynamic model of a system.
Static memory allocation
A programming technique where memory is allocated at compile time. The amount of memory required must be known at design and the allocated amount is fixed and cannot be changed at run-time. The opposite of dynamic memory allocation.
Static model
A model of the static properties of a system, usually including its type definitions, rendered as class diagrams, plus object diagrams and package diagrams.
Static typing
In a language with static types, the type of each variable must be defined at compile time. This allows the compiler to perform a strict set of tests on the program that ensure that certain types of errors cannot occur when the program runs. Java is a statically typed language. Contrast with dynamic typing.
Static variable
The Java and C# name for a class variable. This is the opposite of an instance variable.
Subclass
If B is a subclass of A, then B is derived from A. This means that B inherits all of the attributes and operations of A, but may also add additional attributes and operations. Other terms that means the same thing are B derives from A, or B extends A.
Subtype
Essentially, this means the same as subclass, but expressed in the jargon type theory rather than object-oriented terminology.
Superclass
The opposite relation to subclass. If A is a superclass of B, then B is derived from A.
Supertype
Essentially, this means the same as superclass, but expressed in the jargon type theory rather than object-oriented terminology.
Transition
The fourth (and final) stage of the unified process where the completed system is handed over to the client. This will typically go through a number of iterations as the client acceptance tests the final system.
Type
The type of a variable defines the kind of the data that values of that type can have. See also: static typing and dynamic typing.
UML
See Unified Modelling Language.
Unified Modelling Language
A graphical notation language used extensively in object-oriented analysis and design.
Unified Process
A comprehensive object-oriented analysis and design process, composed of the four stages of inception, elaboration, construction and transition.
Use case
A description of the interaction between an actor and the system under consideration. In the Unified Process, the system requirements are typically expressed through a collection of use cases.
Use case diagram
A graphical notation in Unified Modelling Language used to capture the key features of a particular use case.
Visibility modifier
A statement that modifies a class, attribute or method that determines what other objects in the system can see the given item. See private, protected,package and public visibility.