Common concepts of object-oriented programming languages

• An object is an instance of a certain class.

• A class is a collection of like objects. It is usually named by a common noun in the singular.

• Objects and classes can have attributes and methods:

  • Object attributes (aka instance attributes) store static or variable data about individual objects.

  • Class attributes store static or variable data (e.g., metadata) about the class itself.

  • Object methods (aka instance methods) represent the actions an object “can do” or that can be “done to” an object.

  • Class methods represent actions that can be done to the class itself.

  An attribute x or method f of a class A or object a can typically be referred to as A.x, A.f, a.x, a.f, respectively (dot notation).

• A class is often derived from one or more superclasses (maybe in several levels). Their attributes and methods are then inherited by the derived class but can also be overwritten by subclasses.

• If a class is derived from more than one superclass (multiple inheritance) which are not meant to be instantiated directly, the latter are often called mixin classes.

• Some classes don’t have methods or have only method declarations that contain no implementation and are meant to be overwritten by an “implementation method” in a derived “implementation subclass”. Such classes are typically called “abstract” or “interface” classes, but this terminology is not completely well-defined. They are normally not instantiated directly but rather used to derive “implementation” subclasses that are then instantiated. There are a number of more or less complex “design patterns” describing common practices of how this can be used.

• Packages and Modules are somehow meaningful collections of classes (and maybe other things) that form a separate namespace. A class A in a package or module P can typically be referred to as P.A. Packages and subpackages can typically form a hierarchical structure similarly (and often implemented as) a file folder structure, with modules typically representing the deepest level of this hierarchy, similar to files within a folder structure. To be able to refer to things from package A within package B, one typically needs to import them from A to B, and most programming languages forbid cyclical imports. A similar need for importing often exists if a class needs access to another class’ attributes and methods.