Gewinnung eines geeigneten Objektmodells

Zusätzlich zu den im vorigen Abschnitt angesprochenen Konvertierungen gibt es natürlich noch eine Reihe offener und für das Design des CORBA-Agenten substantielle Kritikpunkte, die nachfolgend aufgezählt sind. Es sei an dieser Stelle daran erinnert, daß das Ziel der Arbeit darin besteht, einen Agenten zu erhalten, der möglichst vollständig objektorientierten Prinzipien entspricht.

1. Zwischen den einzelnen Klassen fehlt (bis auf die Enthaltenseinsbeziehung zur Systemklasse) jegliche Hierarchie
Eine Enthaltenseinshierarchie ist nur ansatzweise (eben mit der Systemklasse) realisiert, eine Vererbungshierarchie fehlt gänzlich. Damit sind zwei wesentliche Möglichkeiten der Objektorientierung noch nicht ausgeschöpft. Polymorphismus wird damit zwangsläufig auch nicht unterstützt.
Dies sind unmittelbare Konsequenzen aus dem Internet-Informationsmodell, das keinerlei Beziehungen zwischen Objektklassen (weder Vererbung noch Enthaltensein) kennt.

2. Die noch vorhandenen Typvariablen widersprechen objektorientierten Grundsätzen
Beispiele für solche Typvariablen in obigen MIB-Ausschnitten sind Type in der Storage-Klasse oder Type in der Device-Klasse. Damit ist es zwar möglich, verschiedene Arten der Objektklasse Storage (durch entsprechendes Setzen der Typvariablen) zu bilden, die Objektstruktur wäre aber für die unterschiedlichen Arten von Speicherobjekten (Hauptspeicher, Festplatten, Magnetbänder, Disketten) dieselbe gewesen; die stark differierenden Eigenschaften der einzelnen Typen werden somit nicht berücksichtigt.
Hier wird das Fehlen einer Vererbungshierarchie im Internet-Informationsmodell deutlich.

3. Die Problematik der Pushbutton-Variablen bleibt bestehen
Das Problem, daß die Wertzuweisung an eine Variable unmittelbar eine Operation auslöst, ist auch in diesem ersten Objektmodell vorhanden.
Dies resultiert aus der Tatsache, daß SNMP keine Action-Protokolldateneinheit kennt.

4. Die Variablentypen beschränken sich nur auf ASN.1-Grundtypen
Auch Variablen mit stark eingeschränktem Wertebereich, wie z.B. OpState oder AdState in der Klasse Processor, besitzen im ersten Objektmodell einen einfachen integer-Datentyp.
Während dieser Punkt auf den ersten Blick als ein ,,kosmetisches`` Problem erscheint, so sind Überlegungen bezüglich der Einschränkung der Wertebereiche von Attributen hinsichtlich späterer Konformitätstests wichtig.

Das objektorientierte Prinzip der Kapselung (Encapsulation) ist in diesem Stadium bereits berücksichtigt:
Wäre diese erste Version als Basis für die Implementierung herangezogen worden, so hätte der IDL-Compiler Rahmendateien erzeugt, in denen die einzelnen Attribute als private gekennzeichnet, also nur über spezielle get-/set-Operationen (deren Rahmen ebenfalls erzeugt würden) zugreifbar gewesen wären.
Es ist somit nicht möglich, auf die Attribute über andere als die bei der Implementierung vorgesehenen Wege zuzugreifen.