OO Definitions



I wrote the below back in the late 1990's trying to educate myself.
Comments/corrections to my understanding or lack thereof are welcome.
---

While there is some variation in terminology/definitions in the
continuously evolving world of OO, the following are provided as an
attempt at a concise collection of common definitions as they apply (or
don't apply) to Fortran 95. Corrections/clarifications are welcome.
These are collected from a variety of sources and are intended only to
summarize my understanding of those sources. All copyright claims
relative to this information are acknowledged. Main source:
comp.object FAQ by Robert John Hathaway III
(www.cyberdyne-object-sys.com/oofaq) and BGTCS by J. Bryson
(www.magicnet.net/~jbryson/OOP.HTML). Detailed attributions are listed
at those sites.

A language is said to be "Object Oriented" if:

· It supports objects that are data abstractions with an interface of
named operations and a hidden local state.

· Objects have an associated type.

· Types may inherit attributes from supertypes.

object-oriented = data abstractions + object types + type inheritance

By this definition, Fortran 95 is an Object Oriented language, however
there are other definitions.

1. Class - A structure which contains abstract data type definitions,
the procedures that operate on those types, and supports inheritance.
This is supported in Fortran 95 via a generic feature called a module
which can contain definitions for all member data and member functions
(methods). Fortran 95 is a 2-level system: all objects are instances
of a class, classes are not themselves accessible to programs (although
member functions and data may be), and classes are not objects, but are
instead object (type, data, and method) definitions.

2. Metaclasses - (e.g. Smalltalk) Classes of classes, classes of
classes of classes...(not directly supported in Fortran 95, can be
emulated via module/use).

3. Methods - (e.g. Smalltalk) The procedure definitions (function
members (or member functions)) of a class.

4. Object (2-Level OO form) - A variable whose internal representation
is not accessible, and upon which only certain operations defined in a
class are performed. An instance of a class.

5. Derived Types (similar to C Structures) - An abstract data type
built from individual intrinsic data types and other derived types. In
Fortran 95, storage sequence is not guaranteed unless the SEQUENCE
statement is included to force sequential definition (omitting SEQUENCE
is an optimization improvement aid for some forms of derived types,
implementation being compiler dependent). In F2K (proposed), SEQUENCE
is required NOT to be specified in some instances of "BIND"ing of
component definitions for interoperability with certain other
languages.

6. Encapsulation - Grouping of data and operations into a single
well-defined unit (such as a module). It is the process of hiding all
of the details of an object that do not contribute to its essential
characteristics.

7. Information Hiding - Details of encapsulated data and operations are
hidden behind an interface. This could involve modules and other
techniques to "hide" API implementation details of classes (data
and methods (procedures or functions and subroutines)) from an
"API" (class/object) user. This is largely intended to improve
safety and accuracy (by decreasing the amount of knowledge required to
be understood by an API user) when designing complex applications (in
practice it does not usually provide significant advantages over a well
designed "procedural" API interface). A secondary intent is to
improve code maintenance through designs in which the internal
implementation details may be changed without impacting the API user.
A PRIVATE statement in a module can be used to hide members or the
entire module or individual components.

8. Compile-time Overloading - Compile-time selection of operation based
upon arguments.

9. Run-time Overloading - Run-time selection of operation based upon
arguments.

10. Function Overloading - Creation of a "generic" function which
performs different operations based upon the data type of an argument.
This can produce additional "call overhead" if implemented such
that run-time parameter/type checking is required versus compile-time
resolution (the usual method).

11. Operator Overloading - Creation of alternate functionality for an
"operator" in a similar manner as for function overloading.

12. Inheritance - A form of reuse. Creation of new class abstractions
from existing abstractions. This is the ability to construct more
complex (derived) classes from simpler (base) classes in a hierarchical
fashion (one class is the parent of another class). The base class
contains the data and procedures (properties) which are common to a
group of derived classes. It is also possible to inherit only a
portion of a class (or module). This minimizes the amount of new code
needed to be developed and tested when adding features to an existing
class. Forms:

· Composition - B "has" an A (Using a module to define a new
module within.)
· Subtyping - B "is" an A (Each object of a derived class
contains one object of the base class. The properties of the base
class are to be passed on to the derived classes (there is no automatic
(run-time) type conversion in Fortran 95).

In Fortran 95, this is analogous to some types of use of a class
definition module by another class definition module.

13. Multiple inheritance - When a class inherits from more than one
parent.

14. Dynamic inheritance - When an object changes or evolves (its class
definition) over time.

15. Shared (repeated) inheritance - When a class appears as a parent
more than once due to multiple inheritance.

16. Polymorphism - the method by which an overloaded
operator/function/message knows what to do based upon the type of
data/object associated with the call. It is the ability of an object
(or reference) to assume (be replaced by) or become many different
forms of object (e.g. to effectively change class or to operate upon
data of a different class (or type)). Some forms of polymorphic
overloading and generic procedures are supported, some other forms can
be emulated but are not directly supported in Fortran 95. Forms:

· Polymorphic functions - functions whose operands can have more than
one type.

· Polymorphic classes - classes whose operations are applicable to
operands of more than one type.

· Parametric polymorphism - (Generic functions) a polymorphic
function that has an implicit or explicit type parameter which
determines the type of the argument for each application of that
function (determined at compile time).

· Inclusion polymorphism - an object can be viewed as belonging to
many different classes that need not be disjoint (there may be
inclusion of classes).

· Dynamic Dispatching (Runtime Polymorphism) - Allows development of
generic (abstract) procedures which work on all classes in an
inheritance hierarchy, yet produces results that depend on which object
was actually used at run-time.

· Generic functions (analogous to C virtual functions) - Functions
that perform different operations based upon the type of the function
parameters (a form of (usually runtime) polymorphism).

17. Generics (C++ Templates) - Refer to the ability to parameterize
types and functions with types. These are classes that use objects as
parameters in their definition. Can be emulated but not directly
supported in Fortran 95.

18. Garbage Collection - A facility in the run-time system associated
with a language which will automatically reclaim objects which are no
longer used. Dynamically allocated storage reclamation in Fortran 95
is manual (as in most other OO languages) .

19. Predicate Classes - An object is automatically an instance of a
predicate class whenever it satisfies a predicate expression associated
with the predicate class. Not directly supported in Fortran 95.

20. Signatures - type abstractions or interfaces of classes.

21. Object Oriented Analysis - the process of understanding the problem
domain, leading to a specification of externally observable behavior; a
complete, consistent, and feasible statement of what is needed; a
coverage of both functional and quantified operational characteristics
(e.g. reliability, availability, performance).

22. Object Oriented Design - the process of taking a specification of
externally available behavior and adding details needed for actual
computer system implementation, including human interaction, task
management, and data management details.

23. Object Oriented Programming - the implementation (coding) of the
resulting OO design.

24. Simula (67) - the first OO language, 1967. Simula 1 was a
simulation language from which derived Simula 67 which is now called
"Simula". Smalltalk was the next major OO language.

25. OO Goals - Faster development (for some complex applications),
increased quality (depending upon level of application developer
expertise in OO techniques and similar factors), easier maintenance
(ditto), enhanced modifiability.

26. OO Pitfalls - Slower execution speed and increased memory usage if
not carefully practiced (may or may not be important to a particular
application). Increased code complexity as compared to procedural
methods for most (relatively simple) applications, but contains very
powerful features for implementing some complex projects or solving
some complex problems. Requires application programmer to be studied
in esoteric (often vague), abstract concepts for which there is some
disparity in definition of terminology and in various implementations
(e.g. Smalltalk vs C++ vs ADA).

.



Relevant Pages

  • Re: I/O in PURE and ELEMENTAL procedures in Fortran 2008
    ... many other purposes such as system programming, interfacing with OS ... I do not advocate a Fortran language which forces me to write ... many of them are written in C (or the API is written for C) which has ...
    (comp.lang.fortran)
  • Re: I/O in PURE and ELEMENTAL procedures in Fortran 2008
    ... many other purposes such as system programming, interfacing with OS ... I do not advocate a Fortran language which forces me to write ... many of them are written in C (or the API is written for C) which has ...
    (comp.lang.fortran)
  • Re: Surprise
    ... haven't seen any Fortran libraries that do that. ... Libraries are a huge part of the reason why one language would be ...
    (comp.lang.fortran)
  • Re: one-liner for characater replacement
    ... convert to another language. ... upgrade to upward compatible versions of the same language. ... Under the above rules of the game, unless the Fortran world announces ...  The user base has not shrunk all that much. ...
    (comp.lang.fortran)
  • Re: interpretive vs. compiled
    ... for specific needs in FORTRAN. ... Nowadays, workstations are also available to engineers, and there's no ... Excel/VBA and much less exposure to programming. ... colleges are wondering what language to use in classes. ...
    (comp.programming)