Das nächste wichtige Ordnungsprinzip bei Bibliotheken sind Hierarchien, wobei es sich nicht immer um Hierarchien im strengen Sinne handelt, sondern häufig nur um gerichtete Graphen ohne Zyklen (DAGs). Entscheidend ist somit die topologische Sortierbarkeit. Die beiden folgenden Beziehungen sind dabei von besonderem Interesse:
In den später folgenden Diagrammen, die Modulhierarchien darstellen, beziehen sich die Pfeile immer auf die Relation (wie z.B. in Abbildung 3.6). Wenn zwischen zwei Modulen A und B die Relation definiert ist, wird A unterhalb von B angeordnet.
Natürlich ist es auch möglich, die Importbeziehungen von Schichten zu betrachten und darzustellen, wie es zum Beispiel in Abbildung 3.5 für die Ulmer Oberon-Bibliothek zu sehen ist.
Im Falle von single inheritance handelt es sich um Hierarchien im strengen Sinne, bei multiple inheritance ergibt diese Relation einen DAG.
Die später folgenden Diagramme, die Typhierarchien darstellen, werden analog zu den Modulhierarchien angeordnet (Basistypen unten, abgeleitete Typen weiter oben), wenngleich in der Literatur überwiegend die umgekehrte Variante bevorzugt wird.
Die beiden wichtigsten Modulvarianten sind Abstraktionen (deferred classes) und implementierende Module. Generell ist es bei objekt-orientierten Bibliotheken interessant, wie Abstraktionshierarchien (auf Basis von Erweiterungsbeziehungen) und Implementierungshierarchien (auf Basis von Importbeziehungen ohne entsprechende Erweiterungen) aufgebaut und miteinander verknüpft sind.
Im idealen Fall läßt sich jedes Modul einer der beiden Kategorien exklusiv zuordnen und in eine entsprechende Hierarchie einordnen. Während das Ziel bei einer Hierarchie von Abstraktionen darin liegt, allgemeine abstrakte Schnittstellen zu offerieren, die in jede gewünschte Richtung verfeinert werden können, liegt der Hauptzweck bei Implementierungshierarchien in der Wiederverwendung von Programmtext. So können vielerlei Algorithmen als Baukasten zur Verfügung stehen und bei mehr als einer Implementierung einer Abstraktion eingesetzt werden. Abbildung 3.7 zeigt die sich daraus ergebende Struktur, wobei Implementierungsbeziehungen gestrichelt dargestellt sind.
Diese ideale Situation wird leider häufig nicht erreicht, da bei den klassischen objekt-orientierten Programmiersprachen die Versuchung zu groß ist, eine Implementierung bereits bei der Abstraktion unterzubringen, die dann im Verfahren der Überdefinition alternativ implementiert werden kann. Auch werden häufig Erweiterungsbeziehungen verwendet, um den Programmtext von Implementierungen wiederzuverwenden.
Ein Beispiel dafür liefert eine frühe Version der Eiffel-Bibliothek (siehe Abbildung 3.8), bei der sich der Aufbau an den Implementierungen orientiert. So offeriert TREE die Funktionalität eines Mehrwegbaumes, wobei es eine Erweiterung von LINKED_LIST ist, um den Programmtext für lineare Listen wiederzuverwenden. Wenn hingegen streng zwischen Abstraktionen und Implementierungen unterschieden wird, könnte der in Abbildung 3.9 demonstrierte Aufbau entstehen, der bemerkenswerterweise völlig ohne multiple inheritance auskommt.