Es ist fast schon Tradition, jeden Programmierkurs mit dem sog. Hallo-Programm anzufangen, mit einem der einfachsten, das es nur gibt. Es gibt jedoch ein noch einfacheres Programm: dasjenige, welches gar nichts tut. Betrachten wir es nun und gewinnen dadurch einen ersten Eindruck, wie ein Java-Programm überhaupt aussieht, wie es übersetzt und ausgeführt werden kann.
Bis hierher bestanden unsere Programme nur aus Sequenzen von Anweisungen — meist Operationsaufrufen —, die nacheinander ausgeführt wurden. Waren die Namen der Operation gut gewählt, stellte eine solche Sequenz eine gute Abstraktion der Programmleistung dar. Wiederholungen waren in (bis jetzt nur rekursiven) Operationen „versteckt“; Sonderfälle wurden als Ausnahmen aus der Kernsequenz ausgelagert. Für die „Programmierung im Großen“, d.h. das Zusammenfügen hinreichend abstrakter Programmbausteine ist genau diese Programmtechnik angebracht und unbedingt zu empfehlen.
Unsere bisherigen Programme waren alle konstante Programme. Dies heißt, dass ihr Ablauf nach dem Übersetzen und Binden jedes Mal gleich war. Variable Programme müssen Eingabedaten haben.
Die Datenbehälter, die wir bis jetzt kennen gelernt haben, waren geeignet, um einen Wert (ein Datenelement) zu speichern (außer Zwei Eimer). Das Eintragen eines neuen Wert in einen solchen Datenbehälter bewirkt, dass der alte Inhalt unwiderruflich verloren geht: Nach bemalen eines Kreis-Objekts ist seine vorherige Farbe nicht wieder auffindbar. Somit „erinnert sich“ ein Datenbehälter nur an seine unmittelbare Vergangenheit, nämlich an den Parameter des letzten Mutatoraufrufs (an die letzte Schreiboperation). Solche Behälter nennen wir Unibehälter.
Eine Klasse besteht — logisch gesehen — aus zwei Teilen: aus der Spezifikation und der Implementierung. In Java — im Gegensatz zu einigen anderen Programmiersprachen wie C++ oder Ada — befinden sich beide Teile im Programmtext der Klasse, und nur das Werkzeug javadoc extrahiert die Spezifikation. Den Rest des Programmtextes nennen wir Implementierung der Klasse.
Derivations from Two-Level Grammars have been defined only in terms of the infinite context-free grammars that can be generated from them. This fact has proven a severe theoretical obstacle to solving the parsing problem for two-level grammars. So far, partial solutions exist for Van Wijngaarden Grammars, Extended Affix Grammars, and Affix Grammars which allow parsing in a single pass from left to right, because these special cases could be handled without developing a full theory of parsing for two-level grammars. In this paper, we propose a new theory of Extended Affix Grammar derivations. The key idea is to use a graph grammar for modelling the two-level derivation process. This allows us to give a precise definition of a parse, which applies correctly to any well-formed Extended Affix Grammar. The concept of multi-pass parsing originates from practical compiler design, where parses are organized as a sequence of passes in order to avoid random access to the full parse tree. We demonstrate how this concept can be incorporated into our theoretical framework by means of canonical graph derivations. This allows us not only to establish the adequacy of the multi-pass approach, but can also be used as a complexity measure for Extended Affix Grammars.
Bis hierher bestanden unsere Programme nur aus Sequenzen von Anweisungen — meist Methodenaufrufen -, die nacheinander ausgeführt wurden. Waren die Namen der Methode gut gewählt, stellte eine solche Sequenz eine gute Abstraktion der Programmleistung dar. Wiederholungen waren in (bis jetzt nur rekursiven) Methoden „versteckt“; Sonderfälle wurden als Ausnahmen aus der Kernsequenz ausgelagert. Für die „Programmierung im Großen“, d.h. das Zusammenfügen hinreichend abstrakter Programmbausteine, ist genau diese Programmtechnik angebracht und unbedingt zu empfehlen.
Wir kennen nun den Begriff Klasse, von der Objekte erzeugt werden. Die Klasse (wie Eimer) wurde von einem Programmierer erstellt und anderen (seinen Benutzern) über ihre Spezifikation zur Verfügung gestellt. Typischerweise werden Klassen in Paketen gruppiert; der Benutzer muss dann das Paket importieren.
Im Besitz der Steuerstrukturen wie Alternativen, Wiederholungen und Rekursion können wir in diesem Kapitel einige bekannte interessante Algorithmen formulieren. Hierzu gehören Sortierverfabren und Bearbeitung von Bäumen. Dabei werden wir uns mit dem Begriff Komplexität rudimentär auseinander setzen.
'%3e%3cpath fill='%23012169' d='M0 0v30h60V0z'/%3e%3cpath stroke='%23fff' stroke-width='6' d='m0 0 60 30m0-30L0 30'/%3e%3cpath stroke='%23C8102E' stroke-width='4' d='m0 0 60 30m0-30L0 30' clip-path='url(%23b)'/%3e%3cpath stroke='%23fff' stroke-width='10' d='M30 0v30M0 15h60'/%3e%3cpath stroke='%23C8102E' stroke-width='6' d='M30 0v30M0 15h60'/%3e%3c/g%3e%3c/svg%3e)