it-swarm.com.de

Wollte Dijkstra eine Modularisierung des Codes, als er über die Trennung von Bedenken schrieb?

Zuerst las ich einen Auszug aus Edsger W. Dijkstras 1974 erschienenem Artikel "Über die Rolle des wissenschaftlichen Denkens":

Lassen Sie mich versuchen, Ihnen zu erklären, was nach meinem Geschmack für jedes intelligente Denken charakteristisch ist. Es ist so, dass man bereit ist, einen Aspekt seines Themas aus Gründen seiner eigenen Konsistenz isoliert zu untersuchen, wobei man ständig weiß, dass man sich nur mit einem der Aspekte beschäftigt. Wir wissen, dass ein Programm korrekt sein muss, und wir können es nur unter diesem Gesichtspunkt studieren. Wir wissen auch, dass es effizient sein sollte und wir können seine Effizienz sozusagen an einem anderen Tag untersuchen. In einer anderen Stimmung fragen wir uns vielleicht, ob und warum das Programm wünschenswert ist. Aber nichts wird gewonnen - im Gegenteil! - wenn diese verschiedenen Aspekte gleichzeitig angegangen werden. Es ist das, was ich manchmal als "Trennung von Bedenken" bezeichnet habe, was, auch wenn es nicht vollkommen möglich ist, die einzige verfügbare Technik zur effektiven Ordnung der eigenen Gedanken ist, die ich kenne. Das meine ich mit "die Aufmerksamkeit auf einen Aspekt lenken": Es bedeutet nicht, die anderen Aspekte zu ignorieren, sondern nur der Tatsache gerecht zu werden, dass der andere aus der Sicht dieses Aspekts irrelevant ist. Es ist gleichzeitig ein- und mehrspurig.

Ich sehe moderne Trennung von Bedenken über die Modularisierung Ihres Codes sprechen. Wenn ich jedoch das obige Zitat lese, verstehe ich dies so, dass Sie Ihren Geist jeweils auf eine bestimmte Aufgabe konzentrieren, ohne sich auf andere Aspekte zu konzentrieren. Dies bedeutet für mich nicht unbedingt, dass Code in modulare Blöcke unterteilt werden muss.

Das heißt, es befindet sich ein Code vor Ihnen, der in einer Datei die Konzepte Ansicht, Repository, Controller, Ereignisbehandlung, Factory usw. in einer Datei enthält.

Hier ein kurzes Beispiel für Code mit Datenzugriff und Ansicht (Ausgabe):

$sql = "SELECT * FROM product WHERE id = " . db_input($id);
$row = db_fetch_array(db_query($sql)); 
<option value="<?=$row['id']?>"<?= $row['ver'] == $row['ver'] ? '  selected="selected"' : '' ?>>Version <?=$row['ver']?></option>

Mit modern OO) konnte ich den Datenzugriff mithilfe des Repository-Musters in eine eigene Datei einfügen, der Ansichtscode kann in eine eigene Dateivorlage eingefügt werden und diese können miteinander verbunden werden, um über einen Controller (oder) zu kommunizieren Action oder Request Handler), und ich kann eine Factory hinzufügen, um verschiedene Abhängigkeiten zu erstellen und zu verkabeln. Und ich kann eine Konfigurationsdatei haben, die diese Fabriken definiert. Sicherlich ist es ein Schritt weg von Single-File-Everything.

Meine Frage zur Trennung von Bedenken lautet wie folgt: Als ich Dijkstras Zitat las, kam mir die Idee, dass er vielleicht nicht unbedingt bedeutete, dass die Trennung von Bedenken "modulare Trennung von Code (in Dateien oder ihre eigenen Funktionen/Methoden/usw.)" ist. und dass er mehr darauf bedacht war, sich auf einen Aspekt des Programms zu konzentrieren, ohne sich auf andere wichtige, aber derzeit nicht zu berücksichtigende Aspekte zu konzentrieren, unabhängig davon, ob sie physisch im Code getrennt sind oder nicht.

Warum belasten wir uns dann mit physischen modularen Codetrennungs- und Entwurfsmustern? Wird es nicht ausreichen, sich nur auf einen Aspekt zu konzentrieren, unabhängig davon, wie Ihr Code aufgebaut ist?

Ich spreche nicht davon, den schrecklichsten Spaghetti-Code zu schreiben und dann nur einen Aspekt davon zu betrachten, das wäre wahrscheinlich eine Belastung. Aber am Ende gehe ich dahin, warum die physische Codetrennung durchführen, warum den Code in getrennte Dateien oder Blöcke (Methoden) aufteilen, wenn es nicht notwendig ist, sich mental auf einen Aspekt zu konzentrieren?

Sollte die Trennung von Bedenken eher eine mentale als eine physische Übung bleiben?
Mit anderen Worten, sollte es eine Trennung zwischen den mentalen (Fokus auf) und den physischen (Code auf Papier) Aspekten der Programmierung geben?

9
Dennis

Dijkstra macht eine explizite Aussage darüber, wie man denkt. Die Modularisierung von Programmen (und Prozessen) - und ihre Wünschbarkeit - ist vielleicht ein Ergebnis dieses Denkens, aber der entscheidende Punkt, den er macht, ist die Bewertung eines Problems. Das Programm ist in der Regel die Lösung eines Problems, und indem er eine "Trennung der Bedenken" befürwortet, bietet er kluge Ratschläge an. Das beste Beispiel dafür ist vielleicht "Optimierung". Der Witz war: "Wenn Sie planen, ein Programm zu optimieren, sollte Ihre erste Strategie sein: Nicht." Mit anderen Worten, Sie möchten sich darauf konzentrieren, zuerst das Programm korrekt zu machen. Es schnell und ausgefallen zu machen, ist ein Anliegen, das getrennt werden sollte - aber auch nicht vollständig entfernt werden sollte.

2
MCL

Trennung von Bedenken ist eine abstrakte Denkweise, die darin besteht, Dinge, die getrennt sind, getrennt zu betrachten müssen nicht verwandt sein.

Modularisierung (Trennung einer nicht verwandten Funktionsgruppe in Module), Kapselung (Ausblenden interner Details der Module) und Abstraktion (Trennung des Allgemeinen vom Spezifischen und der Idee von seiner Implementierung) sind alles Mittel, um diese Denkweise im Bereich des Software-Designs umzusetzen.

14
Christophe

Ich würde vorschlagen, dass, obwohl das Papier von historischem Interesse ist, das, was Dijkstra vor über 40 Jahren mit dem Begriff "Trennung von Bedenken" meinte, heute nicht besonders relevant ist. Heutzutage wird es häufig in Bezug auf die Modulisierung verwendet.

Es gibt eine Fülle von Beweisen dafür, dass die Modulation von großem Nutzen ist und dass diese Vorteile die "Belastungen", die sie uns auferlegt, bei weitem überwiegen. Was auch immer Dijkstra damals bedeutete, ändert nichts an der Tatsache, dass kleine Codestücke, die sich jeweils nur auf eine Sache konzentrieren, zu Code führen, der einfacher zu schreiben, zu lesen, zu verstehen, zu warten und zu testen ist.

9
David Arno

Ich kann Ihnen ein persönliches Beispiel für die Trennung von Bedenken geben, die meiner Meinung nach mit Dijkstras Konzepten vergleichbar ist. Wenn ich ein bestimmtes Thema in Software analysiere, konstruiere ich drei Ansichten.

  1. Zuerst betrachte ich die Daten. Die Daten repräsentieren die logischen Prädikate des Problems. Klassen werden zu abstrakten Entitäten in der realen Welt konstruiert, wobei ihre Attribute die Parameter der Abstraktion sind. Zuordnungen zwischen Klassen repräsentieren funktionale Zuordnungen zwischen den Klasseninstanzen. Zu diesem Zeitpunkt ist kein Code in das Denken involviert und es gibt keine Vorstellung von einer Verarbeitung. Nur eine statische Ansicht der Logik, die mit dem Thema verbunden ist.
  2. Zweitens betrachte ich die Dynamik. Jede Klasse mit einem nicht trivialen Lebenszyklus wird als endliche Zustandsmaschine modelliert. Dies beinhaltet Überlegungen zur Ausführung und Synchronisation der Sequenzierung. Wieder kein Code, der nur herausfindet, wie die Dinge interagieren und ablaufen.
  3. Drittens betrachte ich die Verarbeitung. Hier die eigentliche algorithmische Arbeit, die bei Zustandsübergängen oder bei anderen synchronen Operationen ausgeführt werden muss.

Am Ende erhält man eine dreifach facettierte Ansicht des Gegenstands, die dann als Code in den für den Code selbst und seine Pflege geeigneten Gruppierungen formuliert werden kann. Die drei Facetten sind nicht nur eine mentale Übung. Ich erstelle schriftliche Beschreibungen aller Facetten. Warum? Denn wenn das Thema groß genug ist, kann ich nicht einmal eine vollständige Facette im Kurzzeitgedächtnis halten. Wenn das Thema klein ist, funktioniert fast jeder Ansatz, da Sie alles im Kopf behalten können.

Die Motivation zur Trennung von Bedenken besteht darin, den Einschränkungen des Kurzzeitgedächtnisses des Menschen Rechnung zu tragen. Wir können einfach nicht alles auf einmal in unseren Köpfen tragen, obwohl Computerprogrammierer in der Regel fähiger sind als die meisten anderen Leute, was die Anzahl der Konzepte betrifft, die sie in ihrem Kurzzeitgedächtnis manipulieren können. Um effektiv zu sein, muss das Trennen von Bedenken systematisch einen oder mehrere Aspekte eines Problems ausschließen, um sich auf einen anderen bestimmten Aspekt zu konzentrieren. Das Ausschließen eines Aspekts lässt ihn natürlich nicht aus der Betrachtung verschwinden. Es muss ein Mittel geben, um alle Problemaspekte zu kombinieren, um eine Lösung zu erreichen. Die Erfahrung zeigt, dass das Endergebnis des Trennens und Rekombinierens oft eine verständlichere Lösung ergibt als ein einziger großer Sprung, bei dem viele Aspekte durcheinander gebracht werden können. Dies ist insbesondere dann der Fall, wenn das Problem groß oder kompliziert ist.

2
andy mango

Die Trennung von Bedenken ist ein logisches Konzept, das sich in Ihr Code-Organisationsmodell verbreitet, unabhängig davon, wie Sie es implementieren. Es ist wahr, dass eine Codedatei nur ein technisches Detail ist, eine Möglichkeit, Ihre Software verwaltbar zu halten. Eine einzelne Datei mit einem guten Editor, mit dem eine Erweiterung von Regionen reduziert werden kann, funktioniert möglicherweise auch (für eine Weile) für Sie. Oder eine relationale Datenbank, in der Klassen und Methoden auf Eltern-Kind-Weise in separaten Tabellen gespeichert werden, kann als Speichermedium fungieren. Aber Textdateien sind in einer Welt, in der Quellcode sein muss, schwer zu schlagen

  • tragbar
  • zugriff durch viele verschiedene externe Tools
  • zugriff für mehrere Programmierer
  • versionierbar und vergleichbar
  • skalieren Sie gut mit Betriebssystemen, die im Umgang mit Dateien sehr gut sind

Das Fazit ist, dass wir Menschen nicht sehr gut darin sind, über verschiedene Dinge gleichzeitig nachzudenken oder damit umzugehen. Wir brauchen also ein Modell, das es ermöglicht, über eine Sache gleichzeitig nachzudenken und daran zu arbeiten, ohne die Gefahr zu haben, einen anderen Teil zu ruinieren, den wir zu diesem Zeitpunkt nicht in Betracht ziehen. Wir bauen also, indem wir jeweils einen Stein verlegen, um sicherzustellen, dass die zuvor verlegten Steine ​​die später verlegten Steine ​​nicht beeinträchtigen. Und wenn wir später einen Stein wechseln wollen, dürfen die Dinge nicht zusammenbrechen. Das ist ein Modell, das für unsere einspurigen Köpfe funktioniert.

So wachsen jedoch nicht Pilze oder Algen ... Wie ist das für eine demütigende Tatsache?

1
Martin Maat