2. Neue Subklassen anstelle von Typvariablen

 

Dieser Optimierungsansatz ist die Antwort auf den zweiten Kritikpunkt an der ersten Version des Objektmodells. Durch vorhandene Typvariablen ist 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. Insbesondere ist es innerhalb des vorliegenden Objektmodells also nicht möglich, verschiedenen Typen einer Objektklasse unterschiedliche Eigenschaften (Attribute, Operationen etc.) zuzuweisen, da jedes Objekt der Klasse (gleich welchen Typs) denselben Aufbau hat. So kann man zwar Objekte verschiedenen Typs der Klasse Device erzeugen (durch entsprechendes Belegen der Variablen Type); für jede dieser Komponenten stünden dann jedoch nur drei Variablen (Index, Description und State) zur Verfügung, die, separat betrachtet, nur über beschränkte Aussagekraft verfügen. Dies ist ein weiterer Grund, weshalb die virtuelle, also nicht instantiierbare Klasse Generic_Device zur Wurzel des Vererbungsbaumes wird. Soll nun ein Objekt für eine Systemkomponente erzeugt werden, so wird nicht etwa die Generic_Device-Klasse instantiiert, die nun als Containerklasse für allgemeingültige Attribute dient, sondern eine entsprechende Subklasse.

Ähnlich verhält es sich mit der Storage-Klasse. Hier können zwar die Typen Ram, VirtualMemory, FLCache und SLCache erzeugt werden; es ist jedoch nicht möglich, den einzelnen Typen auch unterschiedliche Eigenschaften zuzuordnen. Deshalb werden die neuen Klassen permanentStorageDevice und volatileStorageDevice eingeführt. Dabei fallen unter die erste Subklasse Komponenten wie Festplatten, Magnetbänder oder Wechselfestplatten. Die zweite Subklasse umfaßt diejenigen Komponenten, die ursprünglich über die Storage-Klasse instantiiert wurden. Als Folge davon werden die Subklassen Ram, VirtualMemory, FLCache und SLCache eingeführt.