DE
RU
EN
ES
ZH
FR
PT
AR
HI
Einleitung: SOLID und Rust – die ideale Kombination
\nDie SOLID-Prinzipien sind grundlegende Regeln des objektorientierten Designs, die helfen, flexiblen, wartbaren und skalierbaren Code zu erstellen. Obwohl Rust keine rein objektorientierte Sprache ist (es verwendet Traits und Strukturen anstelle von Klassen), sind die SOLID-Prinzipien in vollem Umfang darauf anwendbar. In diesem Artikel werden wir jedes der fünf Prinzipien anhand von Codebeispielen in Rust analysieren und zeigen, wie sie beim Aufbau zuverlässiger Systeme helfen.
\nIm Laufe des Artikels werden Sie sehen, wie Rust mit seinem Ownership-System, Traits und Generics die Implementierung von SOLID natürlich und leistungsstark macht. Wir beginnen mit Single Responsibility und enden mit Dependency Inversion und stellen gebrauchsfertige Beispiele zur Verfügung.
\n\n1. Single Responsibility Principle (SRP) – Prinzip der einzigen Verantwortung
\nKernaussage: Jedes Modul, jede Klasse oder Funktion sollte nur einen Grund für eine Änderung haben. In Rust bedeutet dies, dass eine Struktur für eine einzige Aufgabe verantwortlich sein sollte.
\n\nSchlechtes Beispiel (Verletzung des SRP)
\nstruct Report {\n title: String,\n content: String,\n}\n\nimpl Report {\n fn generate(&self) -> String {\n format!("# {}\\n\\n{}", self.title, self.content)\n }\n\n fn save_to_file(&self, path: &str) -> std::io::Result<()> {\n std::fs::write(path, self.generate())?;\n Ok(())\n }\n\n fn send_email(&self, recipient: &str) {\n println!("Sending email to {} with report", recipient);\n }\n}Hier ist die Struktur Report für die Generierung, das Speichern und das Senden verantwortlich – drei verschiedene Gründe für eine Änderung. Dies verletzt das SRP.
Gutes Beispiel (Einhaltung des SRP)
\nstruct Report {\n title: String,\n content: String,\n}\n\nimpl Report {\n fn generate(&self) -> String {\n format!("# {}\\n\\n{}", self.title, self.content)\n }\n}\n\nstruct ReportSaver;\n\nimpl ReportSaver {\n fn save(&self, report: &Report, path: &str) -> std::io::Result<()> {\n std::fs::write(path, report.generate())?;\n Ok(())\n }\n}\n\nstruct EmailSender;\n\nimpl EmailSender {\n fn send(&self, recipient: &str, message: &str) {\n println!("Sending email to {}: {}", recipient, message);\n }\n}Jetzt ist jede Struktur für ihre eigene Aufgabe verantwortlich: Report für Daten und Generierung, ReportSaver für das Speichern, EmailSender für das Senden. Dies vereinfacht das Testen und die Wartung.
2. Open-Closed Principle (OCP) – Prinzip der Offenheit/Geschlossenheit
\nKernaussage: Softwareentitäten sollten für Erweiterungen offen, aber für Modifikationen geschlossen sein. In Rust wird dies durch Traits und Generics erreicht.
\n\nBeispiel: Filtersystem
\ntrait Filter<T> {\n fn apply(&self, items: &[T]) -> Vec<T>;\n}\n\nstruct EvenFilter;\n\nimpl Filter<i32> for EvenFilter {\n fn apply(&self, items: &[i32]) -> Vec<i32> {\n items.iter().filter(|&x| x % 2 == 0).copied().collect()\n }\n}\n\nstruct GreaterThanFilter {\n threshold: i32,\n}\n\nimpl Filter<i32> for GreaterThanFilter {\n fn apply(&self, items: &[i32]) -> Vec<i32> {\n items.iter().filter(|&&x| x > self.threshold).copied().collect()\n }\n}\n\nfn process<T: Clone, F: Filter<T>>(items: &[T], filter: F) -> Vec<T> {\n filter.apply(items)\n}\n\nfn main() {\n let numbers = vec![1, 2, 3, 4, 5, 6];\n let even = process(&numbers, EvenFilter);\n let greater = process(&numbers, GreaterThanFilter { threshold: 3 });\n println!("Even: {:?}, Greater: {:?}", even, greater);\n}Wir können neue Filter hinzufügen, ohne den vorhandenen Code von process zu ändern. Dies ist eine Implementierung des OCP durch Trait-Polymorphismus.
3. Liskov Substitution Principle (LSP) – Prinzip der Substitution von Barbara Liskov
\nKernaussage:
Blogs
Buchempfehlungen
Lesen Sie auch
