# CUPID: Prinzipien für 'erfreuliches' Entwickeln Alle Entwickler sind an einem Punkt in ihrer Karriere wahrscheinlich schon mal den 'SOLID' Prinzipien von Robert C. Martin begegnet. Während diese für eine lange Zeit fast schon als Regeln für sauberen Code galten, hat sich die Meinung vieler Entwickler in den letzten Jahren ein bisschen geändert. Einer dieser Entwickler war Dan North, welcher seine Kritik in seinem Blog veröffentlichte.[^2] Auf seine Kritik wollen wir in diesem Beitrag nicht eingehen, ich lade euch jedoch ein, [seinen Beitrag](https://dannorth.net/blog/cupid-the-back-story/) dazu zu lesen. Stattdessen wollen wir uns eine Alternative anschauen, welche von North vorgeschlagen wurde: CUPID. ## Die einzelnen Prinzipien Wie SOLID ist auch CUPID ein Akronym. Ausgeschrieben sind es folgende Eigenschaften[^1]: - Composable (Zusammensetzbar): Funktioniert gut mit anderen - Unix philosophy: Macht eine Sache gut - Predictable (Vorhersehbar): Macht was man erwartet - Idiomatic (Idiomatisch): Fühlt sich natürlich an - Domain-based (Domänen-basiert): Die Lösungsdomäne gestaltet die Problemdomäne in Sprache und Struktur Im Gegensatz zu SOLID wird hier bewusst nicht von Prinzipien gesprochen. Bei SOLID haben wir eine Reihe von Prinzipien welche uns während der Entwicklung den Weg weisen. Bei CUPID handelt es sich jedoch um Eigenschaften welche unser Code am Ende haben sollte.[^1][^3] Folgend wollen wir uns die einzelnen Eigenschaften im Detail ansehen[^1]: ### Composable - Zusammensetzbar Die erste Eigenschaft von CUPID besagt, dass Code möglichst zusammensetzbar sein sollte. Der Code sollte also beispielsweise eher kleine APIs haben. Kleinere APIs sind einfacher zu lernen und weniger Fehler können geschehen. Man kann es aber auch zu weit treiben. Zu kleine APIs zwingen den Entwickler dazu, viele davon zu kombinieren. Code sollte auch immer seine Absichten aufzeigen. Eine Komponente deren Absichten einfach zu verstehen sind ermöglicht es Entwicklern diese einfach zu finden und auch zu entscheiden, ob es das ist was man sucht. Die Abhängigkeiten von Code sollten auch möglichst klein gehalten werden. Je mehr Abhängigkeiten vorhanden sind, desto grösser ist die Wahrscheinlichkeit, dass die Versionen nicht mit anderen kompatibel sind. ### Unix Philosophie Unix ist ein Betriebssystem welches in 1969 entwickelt wurde und ist seither das meist verbreitete Betriebssystem. In der Form von Open Source Varianten wie Linux und FreeBSD läuft es auf den meisten Geschäftsservern, sowohl in der Cloud wie auch On Premise. Auch die meisten Embedded Systeme und Netzwerkgeräte basieren darauf und auch MacOS und Android wurden aufbauend auf Unix-artigen Systemen entwickelt. Heutzutage ist es sogar optional als Subsystem in Windows verfügbar. Wie konnte ein Betriebssystem, welches in Telekom Forschungslaboren angefangen hat und anschliessend von einem Student als Hobby Projekt kopiert wurde, zum meist verbreiteten Betriebssystem der Welt werden? Ein Aspekt wahr der technische Reiz durch die simple und konsistente Gestaltungsphilosophie von Unix. Die Unix Philosophie besagt, dass Komponenten so geschrieben werden sollten, dass sie gut zusammen arbeiten (bereits obig beschrieben) und, dass sie nur eine Sache machen sollten, diese dafür sehr gut. Auf den ersten Blick erscheint diese Eigenschaft sehr ähnlich wie das *Single Responsibility Prinzip* und für einige Interpretationen des SRP gibt es auch eine gewisse Überlappung. "Eine Sache gut machen" ist jedoch eine *Outside-In* Perspektive, Code Module sollten also einen spezifischen und gut definierten Grund besitzen. SRP wiederum ist eine *Inside-Out* Perspektive, es handelt sich also um die Organisation von Code. ### Predictable - Vorhersehbar Eine weitere Eigenschaft welche sauberer Code nach CUPID besitzen sollte, ist Vorhersehbarkeit. Damit gemeint ist, dass jedes Code Modul sich verlässlich und konsistent so verhalten sollte wie es den Anschein macht, es sollten also keine Seiteneffekte erschienen. ### Idiomatic - Idiomatisch Jeder Entwickler hat seine eigenen Vorlieben wenn es um Code Gestaltung geht, sei es Leerzeichen oder Tabs, Benennungskonventionen oder die Struktur von Code innerhalb einer Datei. Dadurch kann es jedoch für andere Entwickler schwer sein, wenn sie mit unbekanntem Code arbeiten müssen. Gemäss North ist die wichtigste Eigenschaft eines Entwicklers Empathie. Darunter einerseits Empathie gegenüber den Benutzern aber auch Empathie gegenüber zukünftigen Entwicklern. "Menschlich lesbaren" Code schreiben bedeutet, Code für jemand anderes zu schreiben. Das ist mit idiomatischem Code gemeint. ### Domain-based - Domänen-basiert Eine Applikation sollte immer ein Bedürfnis decken. Ein Bedürfnis bedeutet, dass es ein Problem gibt, welches wir mit Software zu lösen versuchen. Unabhängig vom Sinn einer Applikation sollte der Code immer in der Sprache der Problemdomäne beschreiben, was er macht. Hierbei geht es jedoch nicht nur um die Sprache. Domänen-basierte Sprache zu verwenden ist wichtig, aber die Struktur des Codes kann genau so relevant sein. ## Fazit In diesem Beitrag haben wir uns einen Vorschlag für eine zeitgemässe Alternative von SOLID angeschaut. Hierbei versucht CUPID jedoch nicht, SOLID ganz zu ersetzen, sondern präsentiert einen anderen Weg, um die Sauberkeit von Code einzuschätzen. Während die meisten Entwickler mir wahrscheinlich dabei zustimmen würden, dass diese Eigenschaften den Charakter von sauberem Code ziemlich gut beschreiben, muss doch jeder für sich entschieden, ob SOLID dadurch abgelöst werden kann. [^1]: vgl. CUPID: for joyful coding, in: Dan North Blog, 31.07.2025, https://dannorth.net/blog/cupid-for-joyful-coding/ [^2]: vgl. CUPID: the back story, in: Dan North Blog, 31.07.2025, https://dannorth.net/blog/cupid-the-back-story/ [^3]: vgl. SOLID, CUPID & GRASP - three (more) principles that every developer should know about, in: BOLDARE Blog, 31.07.2025, https://www.boldare.com/blog/solid-cupid-grasp-principles-object-oriented-design/