Komplexe Programme
Beim Erlernen der Programmierung entwickeln Sie auch ein besseres Auge für das Lesen von Code (sowohl Ihren eigenen als auch den von anderen). In diesem Abschnitt haben wir den Einsatz von Listen verstanden und geübt, die Benutzerschnittstelle von der Programmlogik zu trennen.
Der folgende (übersetzte) Auszug stammt aus On the role of scientific thought von Edsger W. Dijkstra .
Lassen Sie mich versuchen, Ihnen zu erklären, was für mich charakteristisch für alle intelligente Denkweise ist. Es ist die Bereitschaft, einen Aspekt des betrachteten Themas isoliert zu betrachten, um seiner eigenen Konsistenz willen, in dem Wissen, dass man sich dabei nur mit einem Aspekt beschäftigt. Wir wissen, dass ein Programm korrekt sein muss, und wir können es nur unter diesem Gesichtspunkt untersuchen; wir wissen auch, dass es effizient sein sollte, und können seine Effizienz später untersuchen. In einer anderen Stimmung könnten wir uns fragen, ob und wenn ja, warum das Programm wünschenswert ist. Aber es wird nichts gewonnen – im Gegenteil! – wenn man diese verschiedenen Aspekte gleichzeitig angeht. Dies ist, was ich manchmal als "Trennung der Anliegen" bezeichnet habe, die, auch wenn sie nicht perfekt möglich ist, dennoch die einzige verfügbare Technik ist, die mir bekannt ist, um Gedanken effektiv zu ordnen. Dies ist es, was ich meine, wenn ich sage, dass man seine Aufmerksamkeit auf einen Aspekt lenkt: Es bedeutet nicht, die anderen Aspekte zu ignorieren, sondern lediglich, der Tatsache gerecht zu werden, dass aus der Perspektive dieses Aspekts die anderen irrelevant sind. Es bedeutet, gleichzeitig ein- und mehrgleisig zu denken.
Der Kern von Dijkstras Botschaft ist, dass die Problembereiche eines Programms voneinander getrennt werden müssen – genau das haben wir mit objektorientierter Programmierung und durch die Trennung der Benutzungsschnittstelle von der Programmlogik getan. Jeder Problembereich wurde in seinen eigenen Teil getrennt. Dies kann auch aus der Perspektive der Programmverantwortlichkeiten betrachtet werden. In seinem Blog beschreibt Robert "Uncle Bob" C. Martin den Begriff "Single Responsibility Principle":
Wenn Sie ein Softwaremodul schreiben, sollten Sie sicherstellen, dass Änderungen, wenn sie angefordert werden, nur von einer einzelnen Person oder vielmehr von einer eng verbundenen Gruppe von Personen ausgehen, die eine klar definierte fachliche Anforderung vertreten. Sie möchten Ihre Module von den Komplexitäten der gesamten Organisation isolieren und Ihre Systeme so entwerfen, dass jedes Modul nur für die Bedürfnisse dieser einen Anforderung verantwortlich ist.
[..mit anderen Worten..] Fassen Sie die Dinge zusammen, die sich aus denselben Gründen ändern. Trennen Sie die Dinge, die sich aus unterschiedlichen Gründen ändern.
Eine ordnungsgemäße Programmstruktur und das Befolgen guter Namenskonventionen führen zu sauberem Code. Mit zunehmender Programmiererfahrung werden Sie lernen, dass jedem Programmteil ein klarer Verantwortungsbereich zugewiesen werden kann.