Neue Unterklassen anstelle von Typvariablen

Dieser Optimierungsansatz ist die Antwort auf den zweiten Kritikpunkt an der ersten Version des Objektmodells. Durch vorhandene Typvariablen war es zwar möglich, Objekte verschiedener Typen einer Klasse zu instantiieren. Dies steht jedoch in klarem Widerspruch zum objektorientierten Klassenkonzept, wonach alle Instanzen einer Objektklasse dieselben Eigenschaften aufweisen sollten. Es war innerhalb des vorliegenden Objektmodells also nicht möglich, verschiedenen Typen einer Objektklasse unterschiedliche Eigenschaften (Attribute, Operationen etc.) zuzuweisen; jedes Objekt der Klasse (gleich welchen Typs) hätte den gleichen Aufbau gehabt. So konnte man zwar Objekte verschiedenen Typs der Klasse Device erzeugen (durch entsprechendes Belegen der Variablen Type); für jede dieser Komponenten hätten dann jedoch nur drei Variablen ( Index, Description und State) zur Verfügung gestanden, die, separat betrachtet, nur über beschränkte Aussagekraft verfügen. Dies war ein weiterer Grund, weshalb die virtuelle d.h. nicht instantiierbare Klasse Generic_Device zur Wurzel des Vererbungsbaumes gemacht wurde (siehe auch 3.2.1). Soll nun ein Objekt für eine Systemkomponente erzeugt werden, so wird nicht die Generic_Device-Klasse instantiiert, die nun als Containerklasse für allgemeingültige Attribute dient, sondern eine entsprechende Subklasse.
Ähnlich verhielt es sich mit der Storage-Klasse. Hier konnten zwar die Typen Ram, VirtualMemory, FLCache und SLCache erzeugt werden; es war jedoch nicht möglich, den einzelnen Typen auch unterschiedliche Eigenschaften zuzuordnen. Deshalb wurden die neuen Klassen permanentStorageDevice und volatileStorageDevice eingeführt. Dabei fielen unter die erste Subklasse Komponenten wie Festplatten, Magnetbänder oder Wechselfestplatten. Die zweite Subklasse sollte die Komponenten umfassen, die ursprünglich über die Storage-Klasse instantiiert wurden. Als Folge davon wurden die Subklassen Ram, VirtualMemory, FLCache und SLCache eingeführt.