19,99 €
Mehr erfahren.
- Herausgeber: Espresso Tutorials
- Kategorie: Wissenschaft und neue Technologien
- Sprache: Deutsch
- Veröffentlichungsjahr: 2019
Dieses Praxishandbuch richtet sich an Entwickler und SAP-Berater, die mit der ABAP-Programmiersprache vertraut sind und nachvollziehbare bzw. wartungsfreundliche Algorithmen entwickeln wollen. Lernen Sie Tipps und Tricks zur Fehlerminimierung und Wiederverwendbarkeit Ihrer Codebasis. Der Buchautor zeigt Ihnen anhand anschaulicher Beispiele, was sich hinter Clean Code, Unit-Tests, Refactoring oder Regressionstests verbirgt und wie Sie mithilfe dieser Werkzeuge sowohl Ihre Codequalität als auch Ihren Projekterfolg steigern.
Dazu gehört des Weiteren eine umfassende Dokumentation, unterstützt u. a. durch ADT, ABAP-Doc oder das C4-Modell. Nach einer gut strukturierten Testphase mittels Unit-Tests, SQL Statements und Testattrappen werden Sie dem Releasetermin ruhig entgegenblicken. Und auch im Hinblick auf den Transport Ihrer Entwicklung liefert Ihnen das Buch wertvolle Hinweise, um ungewollte Seiteneffekte zu vermeiden.
- saubere und wartungsfreundliche Algorithmen entwickeln
- ABAP Unit, Coverage Analyzer und den Code Inspector einsetzen
- mit Versionsverwaltungswerkzeugen Modifikationen nachvollziehbar machen
- Zugriff auf Codebeispiele über Open-Source-Lizenz
Das E-Book können Sie in Legimi-Apps oder einer beliebigen App lesen, die das folgende Format unterstützen:
Seitenzahl: 144
Ähnliche
Johannes Gerbershagen
Qualitätsmanagement in der ABAP-Entwicklung unter SAP®
Johannes GerbershagenQualitätsmanagement in der ABAP-Entwicklung unter SAP®
ISBN:978-3-96012-091-9 (E-Book)
Lektorat:Anja Achilles
Korrektorat:Stefan Marschner
Coverdesign:Philip Esch
Coverfoto:© ByTheC | # 639637642 – istockphoto.com
Satz & Layout:Johann-Christian Hanke
Alle Rechte vorbehalten
1. Auflage 2019
© Espresso Tutorials GmbH, Gleichen 2019
URL:www.espresso-tutorials.de
Das vorliegende Werk ist in allen seinen Teilen urheberrechtlich geschützt. Alle Rechte vorbehalten, insbesondere das Recht der Übersetzung, des Vortrags, der Reproduktion und der Vervielfältigung. Espresso Tutorials GmbH, Bahnhofstr. 2, 37130 Gleichen, Deutschland.
Ungeachtet der Sorgfalt, die auf die Erstellung von Text und Abbildungen verwendet wurde, können weder der Verlag noch Autoren oder Herausgeber für mögliche Fehler und deren Folgen eine juristische Verantwortung oder Haftung übernehmen.
Feedback:Wir freuen uns über Fragen und Anmerkungen jeglicher Art. Bitte senden Sie diese an: [email protected].
Inhaltsverzeichnis
Willkommen bei Espresso Tutorials!
Unser Ziel ist es, SAP-Wissen wie einen Espresso zu servieren: Auf das Wesentliche verdichtete Informationen anstelle langatmiger Kompendien – für ein effektives Lernen an konkreten Fallbeispielen. Viele unserer Bücher enthalten zusätzlich Videos, mit denen Sie Schritt für Schritt die vermittelten Inhalte nachvollziehen können. Besuchen Sie unseren YouTube-Kanal mit einer umfangreichen Auswahl frei zugänglicher Videos: https://www.youtube.com/user/EspressoTutorials.
Kennen Sie schon unser Forum? Hier erhalten Sie stets aktuelle Informationen zu Entwicklungen der SAP-Software, Hilfe zu Ihren Fragen und die Gelegenheit, mit anderen Anwendern zu diskutieren: http://www.fico-forum.de.
Eine Auswahl weiterer Bücher von Espresso Tutorials:
Boris Rubarth:
Schnelleinstieg in ABAP: Das Einsteigerbuch
Thomas Stutenbäumer:
SAP-Praxishandbuch ABAP – Teil 1: Konzeption, Entwicklung, Debugging
Thomas Stutenbäumer:
SAP-Praxishandbuch ABAP – Teil 2: Performance, Erweiterungen und Transportwesen
Rüdiger Deppe:
ABAP-Programmierung unter SAP HANA
Christoph Lordieck:
SAP-Schnelleinstieg: ABAP-Entwicklung in Eclipse
Rüdiger Deppe:
Schnelleinstieg in SAP ABAP Objects – 2., erweiterte Auflage
Vorwort
Dieses Buch richtet sich an ABAP-Entwickler und SAP-Berater, die sich mit der Entwicklung von Qualitätssoftware beschäftigen. Es verschafft Ihnen einen Überblick, wie Sie hochwertige ABAP-Entwicklungen erstellen und diese Wertigkeit langfristig erhalten können. Lernen Sie die Themen Clean Code, Unit-Tests, Refactoring oder Regressionstests kennen und steigern Sie mithilfe dieser Werkzeuge sowohl Ihre Codequalität als auch Ihren Projekterfolg.
Mit der Auswahl der Themen richte ich mich gleichermaßen an Anfänger, denen das Thema »Codequalität« noch unbekannt ist, wie auch an fortgeschrittene Programmierer. Kenntnisse in der Programmiersprache ABAP sowie in der Objektorientierung in ABAP (ABAP Objects) sind allerdings Voraussetzung für ein besseres Verständnis.
Beim Erstellen dieses Buches stellte sich mir die Frage, wie ich mit den vielen alltäglichen englischen Fachbegriffen umgehen sollte. Ich habe mich dazu entschieden, die gängigsten englischen Fachbegriffe wie Source Code oder Code für Quelltext, Bug für eine Fehlfunktion, User Interface für die Benutzerschnittstelle oder Unit-Test für einen Komponententest nicht zu übersetzen.
Neben vielen Codebeispielen werden die Themen mit Screenshots visualisiert. Die Screenshots zeigen die ABAP Workbench im SAP NetWeaver Release 7.5 SP01.
Im Text verwenden wir Kästen, um wichtige Informationen besonders hervorzuheben. Jeder Kasten ist zusätzlich mit einem Piktogramm versehen, das diesen genauer klassifiziert:
Hinweis
Hinweise bieten praktische Tipps zum Umgang mit dem jeweiligen Thema.
Beispiel
Beispiele dienen dazu, ein Thema besser zu illustrieren.
Achtung
Warnungen weisen auf mögliche Fehlerquellen oder Stolpersteine im Zusammenhang mit einem Thema hin.
Übungsaufgabe
Übungsaufgaben helfen Ihnen, Ihr Wissen zu festigen und zu vertiefen.
Die Form der Anrede
Um den Lesefluss nicht zu beeinträchtigen, verwenden wir im vorliegenden Buch bei personenbezogenen Substantiven und Pronomen zwar nur die gewohnte männliche Sprachform, meinen aber gleichermaßen die weibliche.
Hinweis zum Urheberrecht
Zum Abschluss des Vorwortes noch ein Hinweis zum Urheberrecht: Sämtliche in diesem Buch abgedruckten Screenshots unterliegen dem Copyright der SAP SE sowie Adobe. Alle Rechte an den Screenshots hält die SAP SE. Der Einfachheit halber haben wir im Rest des Buches darauf verzichtet, dies unter jedem Screenshot gesondert auszuweisen.
1 Die Programmierbeispiele
In diesem Kapitel gebe ich Ihnen einige Informationen zu den Programmierbeispielen, die Sie durch dieses Buch begleiten. Damit Sie dem Inhalt besser folgen und die in Listings dargestellten Beispiele auch selbst ausprobieren können, sollten Sie dieses Kapitel nicht überspringen.
Codebeispiel »abgesagte Angebote«
Als Demonstrationswerkzeug diente mir bei der Erstellung dieses Buches ein Codebeispiel, dem ich in den nachfolgenden Kapiteln den Namen »abgesagte Angebote« gegeben habe. Dieses Codebeispiel erstellt eine Auswertung über Angebote, deren Positionen vom Kunden mit dem Grund »zu teuer« abgesagt wurden. Die Auswertung enthält die Preisspanne der abgesagten Positionen sowie das Verhältnis zwischen der Anzahl abgesagter Positionen und der Anzahl der gesamten Positionen. Die Preisspanne bezieht sich immer auf eine konkrete Währung und eine bestimmte Menge. Die Mengen werden in der im Materialstamm hinterlegten Basismengeneinheit angegeben. Es erfolgt keine Umrechnung der unterschiedlichen Währungen in den einzelnen Positionen.
Den Source Code habe ich Ihnen im GIT-Repository https://github.com/germanysources/clean_code_demo zur Verfügung gestellt. Darin wurden zu Demonstrationszwecken hauptsächlich deutsche Begriffe und Kommentare verwendet. Der Source Code ist mit SAP NetWeaver Releases 7.40 und höher kompatibel.
Wichtigste Entwicklungsobjekte des Codebeispiels:
Report
zangebote_abgesagt
: übernimmt die Anzeige der Auswertung im ALV Grid,
Klasse
zangebote_abgesagt
: liest die Angebote von der Datenbank und bereitet die Daten für die Auswertung auf,
Klasse
zangebote_abgesagt_stub_demo
: enthält dieselbe Funktionalität wie die Klasse
zangebote_abgesagt
; demonstriert eine in
Abschnitt 4.6
beschriebene Testattrappe.
Das angegebene Repository enthält zwei Varianten in zwei separaten Branches:
1. Branch: Master
Die erste Variante setzt die Anzeige- und Änderungsmöglichkeit für Angebote im SD-Modul voraus. Die Kopfdaten der Angebote werden in dieser Variante aus den Tabellen vbak und vbkd und die Positionsdaten aus der Tabelle vbap ermittelt.
2. Branch: WITHOUT_SD_TABLES
Die zweite Variante ist unabhängig von den Modulen SD und MM und kann damit insbesondere auf miniSAP-Installationen verwendet werden. In dieser Variante werden alle in den Modulen SD und MM vorhandenen Datenbanktabellen durch z-Tabellen ersetzt. Tabelle 1.1 gibt Ihnen einen Überblick, welche Tabellen durch z-Tabellen getauscht wurden. Für alle z-Tabellen existieren Pflege-Views, die Sie über die Transaktion SM30 erreichen.
Bedeutung
Tabelle SD/MM-Modul (wird im Masterbranch verwendet)
z-Tabelle (wird im WITHOUT_SD_TABLES-Branch verwendet)
Kopfdaten Angebote
VBAK,VBKD
ZANGEBOT_VBAK
Positionsdaten Angebote
VBAP
ZANGEBOT_VBAP
Kundenstamm
KNA1
ZANGEBOT_KUNDEN
Materialstamm
MARA
ZANGEBOT_MATERIA
Materialtexte
MAKT
ZANGEBOT_MATTEXT
Tabelle 1.1: Tausch der Datenbanktabellen im Master- und im WITHOUT_SD_TABLES-Branch
Für die Installation benötigen Sie das Open-Source-Versionsverwaltungswerkzeug abapGit, das in Abschnitt 6.1.2 vorgestellt wird. Falls Sie noch nicht mit abapGit gearbeitet haben, empfehle ich Ihnen, zunächst Abschnitt 6.1.2 zu lesen.
Codebeispiele aus dem Flugbetrieb
Das Codebeispiel »abgesagte Angebote« erstellt nur eine Auswertung. Neben dem Erzeugen von Auswertungen wird ABAP aber auch häufig dazu verwendet, Buchungen zu erzeugen oder zu ändern und Informationen per E-Mail oder per IDOC zu verschicken. Diese Datenmanipulationen werden anhand separater Codebeispiele verdeutlicht, die wie viele ABAP-Codebeispiele kleine Ausschnitte aus der Abwicklung eines Flugbetriebes zeigen. Diese Beispiele sollen Ihnen zur Verdeutlichung des geschriebenen Textes dienen, ohne dabei wie das Codebeispiel »abgesagte Angebote« eine konkrete Anforderung zu implementieren. Sie finden die zugehörigen Listings auch unter dem folgenden Download-Link.
Download-Link Listings
https://de.espresso-tutorials.com/_QM.php
Nach dem Download verwenden Sie wieder abapGit, um diese Listings in Ihr System einzubinden.
Quellcode-Beispiele im Querformat betrachten
Um die Lesbarkeit der Quellcode-Beispiele in Ihrem E-Book-Lesegerät zu verbessern, empfehlen wir, den Quellcode im Querformat zu betrachten.
2 Robustes Softwaredesign
Wie kann bereits in der Entwurfs- und Entwicklungsphase das Grundgerüst für ein erfolgreiches Projekt gelegt werden? In diesem Kapitel werde ich Ihnen einige Ideen dazu aufzeigen.
Ich teile die unter Experten häufig vertretene Meinung, dass durch die Entwicklung von Clean Code Software robust gestaltet wird. Clean Code umfasst eine Reihe von Maßnahmen, um Software aufgeräumt und sauber zu gestalten. Durch Ordnung und Klarheit können Sie folgende Ziele realisieren:
Nachvollziehbarkeit der Algorithmen,
Vermeidung von Stolperfallen,
einfache Wartung: Entwickler, die bisher nicht in das Projekt involviert waren, können den Source Code trotzdem lesen, verstehen und warten,
Fehlerminimierung: viele Bugs werden schon in der Testphase und nicht erst im produktiven Einsatz gefunden,
Wiederverwendbarkeit: dieselben Funktionen müssen nicht jedes Mal kopiert oder neu geschrieben werden.
In den nächsten Abschnitten stelle ich Ihnen einige Maßnahmen für die Entwicklung von Clean Code vor.
2.1 Übersichtlicher und verständlicher Source Code
Bei größeren Projekten empfiehlt es sich, den Source Code übersichtlich und verständlich zu gestalten. In der folgenden Liste möchte ich Ihnen daher einige einfache Gestaltungsrichtlinien vorstellen, die dazu beitragen:
1. Prozeduren kurz halten:
Nicht mehr als 60 Zeilen gibt z.B. das Open-Source-Projekt
https://github.com/sbcgua/mockup_loader
an,
Makros sollten nicht mehr als fünf Zeilen umfassen, ist meine Empfehlung (die Variablennamen &1, &2, &3 ... lassen längere Makros schnell unübersichtlich wirken).
2. Aussagekräftige Programm-, Klassen-, Methoden-, Prozedur- und Parameternamen vergeben:
oft verwendete Abkürzungen dokumentieren,
einheitliche Begriffe und Abkürzungen verwenden, die dem gesamten Team geläufig sind.
Aussagekräftige Namen und auch Kommentare sollen die Implementierung so detailliert beschreiben, dass sie von jedem Entwickler verstanden werden kann. Wofür wurde unser Programm konzipiert? Welchen Zweck erfüllt diese Prozedur? Mit welchen Werten sind die Eingabeparameter zu übergeben? Unter welchen Umständen werden änderbare Parameter (CHANGING) abgewandelt? Unter welchen Umständen werden Ausnahmen oder Fehlermeldungen geworfen? Die entsprechenden Antworten sollten wir den Namen bzw. Kommentaren entnehmen können.
Innerhalb von Prozeduren können Sie mit freiformulierten Kommentaren den Zweck Ihrer Anweisungen ausdrücken. Nach außen können Sie die für die Verwendung der Prozedur relevanten Informationen als ABAP-Doc-Kommentare bereitstellen. Listing 2.1 zeigt die Platzierung eines ABAP-Doc-Kommentars vor der entsprechenden Methodendefinition.
"! Liest alle Positionen (abgesagte und "! nicht abgesagte Angebote). "! @parameter angebots_nummern | Positionen dieser "! Angebote werden gelesen "! @parameter positionen | alle Strukturfelder "! werden mit den Werten aus der Tabelle vbap "! uebergeben METHODS get_angebotspositionen IMPORTING angebots_nummern TYPE zangebots_kopfdaten EXPORTING positionen TYPE zangebots_positionen.
Listing 2.1: Beschreibung einer Methode mit ABAP-Doc-Kommentaren
Auf die Syntax der ABAP-Doc-Kommentare gehe ich nochmal detailliert in Abschnitt 3.3 ein.
Die verwendeten Namen sollten einer eindeutigen Terminologie folgen. Sie sollten sie daher sinnvollerweise mit den Prozesseigentümern und den Entwicklern abstimmen, damit die Terminologie in einem klaren Zusammenhang mit dem im Code abgebildeten Geschäftsprozess steht. APIs bzw. Bibliotheken, die technischer Natur sind (z.B. die RTTS[RunTime Type Services]-Klasse cl_abap_typedescr), können mit technischen Fachbegriffen beschrieben werden. Bei anwendungsspezifischen Quelltexten ist die Verwendung von Fachbegriffen, die dem Geschäftsprozess entlehnt wurden, oft aussagekräftiger als eine rein auf die technische Umsetzung fokussierte Terminologie.
Aussagekräftige Namen: Tell don’t ask
Die Klasse zangebote_abgesagt enthält die Methode get_angebotskopfdaten. Aus technischer Sicht hätte ich diese Methode auch kurz get_vbak nennen können, da hier Datensätze aus der Tabelle vbak gelesen werden. Der Methodenname get_vbak wirft allerdings einige Fragen auf. Wenn Sie die Abkürzung vbak für »Vertriebsbelege Kopfdaten« nicht kennen, würden Sie sich sicherlich fragen: Was bedeutet vbak? Und selbst wenn Sie sie kennen, würden Sie sich vielleicht fragen, welche Vertriebsbelege aus der Tabelle vbak gelesen werden (Angebote, Kontrakte oder Aufträge).
3. Versionsverwaltungswerkzeuge richtig nutzen:
Änderungshinweise mit Autor und Datum in den einzelnen Zeilen erschweren nach vielen Modifikationen die Lesbarkeit und Verständlichkeit. Versionsverwaltungswerkzeuge dokumentieren bereits alle Änderungen mit Autor, Datum und den eingefügten, geänderten sowie gelöschten Zeilen.
Das Versionsverwaltungswerkzeug der ABAP Workbench ist, wie in Abbildung 2.1 ersichtlich, über den Menüpfad
Hilfsmittel
•
Versionen
•
Versionsverwaltung
zu erreichen. Bei der Freigabe eines Transportauftrages wird automatisch eine neue Version erzeugt. Die älteren Versionen gehen nicht verloren, wenn Sie auf Änderungshinweise im Code verzichten.
Inzwischen gibt es auch Open-Source-Versionsverwaltungswerkzeuge wie
git®
(
https://git-scm.com
) und
abapGit
(
https://github.com/larshp/abapgit
), die Änderungen im Source Code optimal nachvollziehbar machen. Beide Werkzeuge stelle ich in
Abschnitt 6.1
detailliert vor.
Abbildung 2.1: Versionsverwaltung in der ABAP Workbench
2.2 Trennen der Belange (Separation of Concerns)
Unter dem Begriff Trennen der Belange versteht man die Abgrenzung der Ein- und Ausgaben von der Anwendungslogik. Die Anwendungslogik enthält nur Operationen mit ABAP-Variablen und ist unabhängig von externen Ressourcen. In ABAP-Programmen sollten die nachfolgend beschriebenen Aspekte separat von der Anwendungslogik implementiert werden.
2.2.1 SQL-Statements
SQL-Statements sollten an möglichst wenigen Stellen gebündelt werden (z.B. nur in eigenen Prozeduren oder hinter eigenen Interfaces).
Dies bringt Ihnen während der Entwicklungs- und Testphase einige Vorteile:
Die SQL-Statements können durch
Testattrappen
ersetzt werden, wie in
Abschnitt 4.6
dargestellt wird. Eine Testattrappe liefert immer dasselbe Resultat, auch wenn sich die Datensätze in der Datenbank ändern. Mit ihrer Hilfe können Sie einzelne Komponenten der Anwendungslogik isoliert testen.
Die Anwendungslogik wird nicht so stark an das Datenbankschema gekoppelt. Schemaänderungen haben somit weniger Auswirkungen auf die Anwendungslogik.
SQL-Statements im Codebeispiel »abgesagte Angebote«
In der Klasse zangebote_abgesagt wurden die SQL-Statements in den folgenden Methoden gebündelt:
in der Methode get_angebotskopfdaten, die die Kopfdaten der Angebote (Tabelle vbak) liest, in der Methode get_texte, die die Materialtexte und Kundenamen liest, sowie in der Methode get_angebotspositionen, die die einzelnen Positionen (Tabelle vbap) liest.Die restlichen Methoden dieser Klasse enthalten die Anwendungslogik ohne SQL-Statements.
2.2.2 Präsentationslogik (User Interface)
Zum User Interface gehören alle Elemente, die direkt mit dem Benutzer interagieren (Table Controls, ALV Grids, Pop-ups, Meldungen mit der Anweisung MESSAGE usw.). Es spricht Vieles dafür, das User Interface von der Anwendungslogik zu separieren. Dadurch gibt es bei Änderungen des User Interfaces weniger Seiteneffekte auf die Anwendungslogik und umgekehrt.
Ein weiterer Vorteil ist: Sie können dem Benutzer dieselbe Anwendungslogik auf verschiedene Arten präsentieren – z.B. einmal in der SAP GUI und einmal im Web Dynpro.
Mit der Trennung von User Interface, Anwendungslogik und SQL-Statements werden außerdem Dynpro-Wechsel zwischen zwei schreibenden SQL-Statements oder zwei Verbuchungsbausteinen vermieden. Solch ein Dynpro-Wechsel erzeugt eine implizite COMMIT WORK-Anweisung und durchbricht damit das Transaktionskonzept. Erst nachdem alle schreibenden SQL-Statements und Verbuchungsbausteine gerufen wurden, kann ein Dynpro-Wechsel erfolgen.
Im Codebeispiel »abgesagte Angebote« wurde das User Interface im Report zangebote_abgesagt implementiert. Die Trennung von User Interface und Anwendungslogik wurde durch den Einsatz des Bausteines REUSE_ALV_GRID_DISPLAY sowie der Klasse zangebote_abgesagt erreicht, die die Daten in der Methode get_angebote passend aufbereitet. Wenn Sie sich den Report zangebote_abgesagt in Listing 2.2 genauer anschauen, entdecken Sie einen TRY-Block, der die klassenbasierte Ausnahme zcx_angebot_abgesagt auffängt. Diese Ausnahme wird in der Anwendungslogik geworfen und erst im START-OF-SELECTION-Ereignis mithilfe der Anweisung MESSAGE not_found TYPE 'S' in eine sichtbare Meldung umgewandelt. Das Verhalten der MESSAGE-Anweisung ist abhängig vom eingesetzten User Interface. Daher sollte sie streng genommen nicht in der Anwendungslogik, sondern erst im User Interface verwendet werden.
Klassenbasierte Ausnahmen in der Anwendungslogik
Verwenden Sie in der Anwendungslogik klassenbasierte Ausnahmen als Transportmittel für eine Fehlermeldung. Fangen Sie die Ausnahme erst im User Interface ab und wandeln Sie sie dort in eine für den Benutzer sichtbare Fehlermeldung um.
Buchempfehlung
Einen Leitfaden zur Implementierung von Ausnahmeklassen finden Sie im Buch »Schnelleinstieg in SAP ABAP Objects« (Deppe, Espresso Tutorials, 2015).
Listing 2.2: Auszug aus dem Report zangebote_abgesagt
MVC-Prinzip
Das MVC-Prinzip löst die Trennung von Anwendungslogik und User Interface durch die Einführung von drei Abstraktionsniveaus:
1. M für Model: stellt die Prozeduren der Anwendungslogik bereit,
2. V für View: enthält die Komponenten der Präsentationslogik,
3. C für Controller: das Bindeglied zwischen Anwendungslogik und Präsentationslogik.
Jedes Abstraktionsniveau wird in einer separaten Klasse oder in einer separaten Funktionsgruppe implementiert.
Web-Dynpro-Applikationen werden nach dem MVC-Prinzip erstellt. Hierbei entspricht die Assistenzklasse dem Model und der Componentcontroller dem Controller. Den Componentcontroller verwenden wir, um Attribute und Methoden bereitzustellen, die in allen Views zum Einsatz kommen. Die Methoden des Componentcontrollers delegieren die Aufrufe an die Assistenzklasse, während die Views nur die Präsentationslogik enthalten. Aufgabe eines Views ist es, auf Benutzeraktionen zu reagieren und die Aufrufe an die entsprechenden Methoden des Componentcontrollers zu delegieren.
2.3 Gestaltungsrichtlinien für Fortgeschrittene
In den letzten beiden Abschnitten haben Sie bereits einige einfache Gestaltungsrichtlinien kennengelernt. In diesem Abschnitt wende ich mich mit weiteren Grundsätzen insbesondere an fortgeschrittene Entwickler. Mithilfe dieser Richtlinien tun Sie sich bei Quelltextmodifikationen und -erweiterungen leichter, die bestehende Funktionalität Ihrer Algorithmen zu erhalten.
2.3.1 Delegation
Delegation bedeutet, untergeordnete Prozeduren oder Objekte aufzurufen. Prozeduren können dabei Methoden, Unterprogramme oder Funktionsbausteine sein.
Delegation in der Klasse zangebote_abgesagt
Die öffentliche Methode get_angebote ruft die private Methode get_angebotskopfdaten. D.h., die Methode get_angebote »delegiert« den Aufruf an die Methode get_angebotskopfdaten.
