Object Oriented Programming Languages
| C++ | Smalltalk | CLOS | Eiffel | Objective C | |
|---|---|---|---|---|---|
| Strong typing | Y | N | N | Y | Y |
| Encapsulation
control of access from clients control of access from subclasses |
Y Y |
Y N |
N N |
Y Y |
Y Y |
| standard class library | N | Y | N | Y | Y |
| parameterised classes | P | - | - | Y | N |
| multiple inheritance | Y | N | Y | Y | N |
| packaging - scoping of class names | N | N | Y | N | N |
| assertions and constraints | N | N | N | Y | N |
| metadata at run-time | N | Y | Y | N | N |
| memory management | N | Y | Y | Y | N |
| development environment | Y | Y | Y | Y | N |
| persistence | Y | N | N | Y | N |
| efficiency (static binding when possible) | Y | N | N | Y | Y |
Y = feature present, N = not, P = planned, - = not applicable (not needed in weakly typed languages).
| Strong typing | This specifies the time at which types are checked. When types are checked (and enforced) at compile time, those languages are said to be strongly typed. If type checking is delayed until runtime, those languages are said to be weakly typed. |
| Encapsulation | The degrees of visibility supported and enforced. For example, C++ has 3 levels: private, protected and public. |
| Standard class library | Most OO languages include a library of useful generic classes, which may be used as is or customised to meet a specific need through the creation of subclasses. The availability of such a library also means that many components need not be re-implemented by the programmer. |
| Parameterised classes | Some languages allow parameterised classes to be defined that can be applied in several cases that differ only in the types of the parameters. E.g. a generic list class may be defined that is parameterised on the kinds of things it can list. So the name list class can be used to create a list of names, a list of integers, etc. |
| Multiple inheritance | A class can have more than one parent class. |
| Packaging | The class is not an adequate structuring construct for large systems. Most object systems and OOPLs lack support for creating and encapsulating logical partitions of classes. Another related problem is that object systems require that the names of classes and objects be unique. Packages provide another way of partitioning a system into separate components with their own name-spaces, within which names need to be unique. |
| Assertions and constraints | These improves the odds that the behaviour of a class matches the expectations of its clients. We can also do this by writing natural language descriptions of the desired behaviour, but more formalised definitions of these in the form of assertions and constraints (object behaviour rules) can be better understood and enforced. |
| Metadata | Data about data (e.g. class definitions) is metadata. Such data about classes allow the developer to change class definitions, define new classes, etc., at run time. |
| Memory management | This refers to the sophistication of the garbage collection schemes. When a particular object is no longer needed, garbage collection mechanisms retrieve the space allocated for the object. |
| Development environment | Browsers, compilers, editors and other tools that aid the developer in developing and debugging code are especially important for OOPLs as the complexity of keeping track of - and ensuring the correctness of - the fine-grain modularity is difficult. |
| Persistence | Reflects presence or absence of support for access to persistent objects - either implicitly (seamlessly) or explicitly (via an API). |
| Efficiency | This category indicates which languages have the option for compile-time binding, which improves efficiency, but reduces flexibility. Run-time binding, or method resolution - which determines how the appropriate method is accessed and executed when a message is received - reduces the efficiency of an OOPL. This becomes increasingly important when the inheritance tree is deep, as methods may be inherited from several different ancestors at several different levels. |
(CLOS = Common LISP Object System).