SOLID-Prinzipien

Einfach erklärt

Die SOLID-Prinzipien sind fünf grundlegende Designprinzipien für objektorientierte Software, die wartbaren, erweiterbaren und testbaren Code fördern. Sie wurden von Robert C. Martin (Uncle Bob) formuliert und sind heute Standard in professioneller Softwareentwicklung. Für KI-Systeme sind SOLID-Prinzipien besonders relevant: ML-Pipelines, Inferenz-Services und Daten-Prozessoren werden schnell komplex – gute Architektur verhindert, dass sie unwartbar werden.

SOLID ist ein Akronym für fünf Prinzipien, die Robert C. Martin (Uncle Bob) populär gemacht hat. Sie helfen dabei, Software zu bauen, die sich leicht ändern und erweitern lässt.

Warum ist das wichtig?

Ohne gute Struktur wird Code schnell zum “Spaghetti-Code”: Alles hängt mit allem zusammen, eine kleine Änderung bricht zehn andere Stellen. SOLID verhindert das.

Die fünf Prinzipien auf einen Blick:

Buchstabe	Prinzip	Bedeutung
S	Single Responsibility	Jede Klasse macht nur eine Sache
O	Open/Closed	Erweiterbar ohne bestehenden Code zu ändern
L	Liskov Substitution	Unterklassen müssen wie ihre Oberklasse funktionieren
I	Interface Segregation	Kleine, spezifische Schnittstellen
D	Dependency Inversion	Abhängigkeiten über Abstraktionen, nicht konkrete Klassen

Praxis-Beispiel:

Stell dir vor, du baust einen KI-Chatbot. Ohne SOLID hättest du eine riesige Klasse, die API-Calls macht, Datenbank speichert, E-Mails sendet und Logs schreibt. Mit SOLID hast du kleine, austauschbare Bausteine – du kannst den LLM-Provider wechseln, ohne den Rest anzufassen.

Technischer Deep Dive

S – Single Responsibility Principle

Eine Klasse sollte nur einen Grund haben, sich zu ändern.

// ❌ Schlecht: Klasse macht zu viel
class UserService {
  createUser() { ... }
  sendWelcomeEmail() { ... }
  generateReport() { ... }
}

// ✅ Gut: Getrennte Verantwortlichkeiten
class UserService { createUser() { ... } }
class EmailService { sendWelcomeEmail() { ... } }
class ReportService { generateReport() { ... } }

O – Open/Closed Principle

Offen für Erweiterung, geschlossen für Änderung.

// ✅ Neue Embedding-Provider hinzufügen ohne bestehenden Code zu ändern
interface EmbeddingProvider {
  embed(text: string): Promise<number[]>;
}

class OpenAIProvider implements EmbeddingProvider { ... }
class CohereProvider implements EmbeddingProvider { ... }
// Neuer Provider → neue Klasse, kein bestehender Code geändert

D – Dependency Inversion Principle

Abhängigkeiten auf Abstraktionen, nicht auf konkrete Implementierungen.

// ❌ Direkte Abhängigkeit
class RAGService {
  private db = new PineconeClient(); // fest verdrahtet
}

// ✅ Abstraktion
class RAGService {
  constructor(private vectorStore: VectorStore) {} // austauschbar
}