Prozedurale Programmierung und programmiersprachenunabhängige Konzepte?

[Static]

Guten Abend, ich habe mal wieder ein großes Fragezeichen über dem Kopf bei den oben genannten Themen und finde keine für verständlichen Erklärungen zu den beiden Themen. Ich versuche es mal, vielleicht mögt ihr ja Ergänzungen vorschlagen.

Prozedurale Programmierung: Eine Gesamtlösung (Software) wird in Teilaufgaben unterteilt. Zum einen ist die Umsetzung damit einfacher und zum Anderen kann der Quellcode für andere Projekte genutzt werden. Die Umsetzung soll mittels "einfacher" Programmiersprachen erfolgen wie bspw. Pascal oder C.

Mir erklärt sich der Sinn dahinter nicht. Wenn ich ein Programm erst in Pascal erstelle und später nochmal in C++ oder so, welchen Vorteil habe ich? Der zeitliche Aufwand dürfte doch gleich sein. Und warum zählt C zu einer simplen Programmiersprache in diesem Fall?

programmiersprachenunabhängige Konzepte: Hierzu finde ich gar nichts. Ich habe viel überlegt und glaube damit sind diese "Pseudocode" Pläne gemeint die bspw. für Datenbanken genutzt werden? Mir fällt die genaue Bezeichnung hierfür gerade nicht ein. In den Plänen sind die Abläufe mit Rechtecken und Kreisen beschrieben. Dazu gibt es noch Abhängigkeiten.

[stefan.macke]

Ich vermute, dass mit den programmiersprachenunabhängigen Konzepten die drei Bausteine von Algorithmen gemeint sind: Sequenz, Verzweigung und Wiederholung. Diese Konzepte gibt es in allen Sprachen.

Es könnten auch Konzepte gemeint sein wie Abstraktion oder Kapselung.

Oder eher "moderne" Konzepte wie "Don't repeat yourself" und "Keep it simple'.

All diese Konzepte sind nicht an eine Programmiersprache gebunden, sondern können in allen Programmen angewendet werden, egal, welche konkreten Mittel die Sprache bereitstellt.

[Static]

Hi Stefan, danke schon mal für deine Vorschläge.

Das hier wäre dann ein unabhängiges Konzept mit den Algorithmen Bausteinen, oder?

Das DRY Prinzip sagt doch nur aus, dass sich Code nicht wiederholen soll. Bei großen Projekten ist diese Überprüfung doch nur mittels passender IDEs möglich, die dies erkennen?

[pr0gg3r]

Das DRY Prinzip sagt doch nur aus, dass sich Code nicht wiederholen soll. Bei großen Projekten ist diese Überprüfung doch nur mittels passender IDEs möglich, die dies erkennen?

Nein, das musst du bei der Planung bzw. der Architektur deiner Projekte selber beachten. Stell dir einfach mal vor, du programmierst mit deinem geposteten Nassi-Schneiderman-Diagramm ein Spiel. Jetzt hast du evtl. verschiedene Bots, davon Gegner aber auch friedliche wie zB Tiere. All diese müssen irgendwie um einen Baum herumgehen können. Da wäre es nicht sinnvoll, den Pathfinding-Algo jedes mal neu zu programmieren sondern du programmierst den ein mal und verwendest ihn modular für alles, was irgendwo einen Weg finden muss.

Ein anderes Beispiel:

Ich hatte neutlich einen Code, bei dem es zig Buttons gab und in jedem Button-onClick-Event der gleiche Code per Copy und Paste der gleiche Algo abgelaufen ist (mit anderen Parametern, aber jedes mal der Algo neu implementiert). Also habe ich den Algo abstrahiert, eine Funktion erstellt und rufe nun nur noch die Funktion auf (bzw. mittlerweile werden die Buttons per Laufzeit erstellt). Dadurch hat man ganz andere Möglichkeiten und Vorteile, zB wenn sich der Algo ein mal ändert, muss ich nicht an hundert Stellen gleichzeitig anpassen. Aber: man muss schon selber daran denken (was der vorige Programmierer bei meinem Bsp. nicht getan hatte).

Ein anderes Prinzip wäre zB EVA - Eingabe, Verarbeitung, Ausgabe (oft sieht man auch während der Verarbeitung weitere Ein- oder Ausgaben, aber das widerspricht dann dem Prinzip).

[Static]

Ah danke für die anschauliche Verdeutlichung pr0gg3r.

Da haben wir es wieder, das Nassi-Schneiderman-Diagramm eignet sich doch zum Erstellen von programmiersprachenunabhängigen Konzepten oder? So ein Spiel stelle ich mir bspw. sehr kompliziert und umfangreich vor, so dass sich das Diagramm maximal für den von dir angesprochenen Pathfinding-Algo anbietet. :confused: