Kommunikation von Klassen und Methoden
Beitrag
von DeathAndPain (Top Expert / 1964 / 261 /
415
)
»
Ja, das sagte ich bereits, dass funktionale Methoden etwas sehr Schönes sind. Das ist aber kein Vorteil von OO, sondern allenfalls von dessen Implementierung in ABAP, denn syntaktisch wäre es kein Problem, auch funktionale Formroutinen in ABAP einzubauen.Wenn man gewohnt ist, Methoden zu schreiben, IST die Methode die Prüfung. Schon hier zeigt sich eine völlig andere Denke. Dann heißt die Methode eben nicht "GET_DONOR" gefolgt von der Prüfung, ob der Spender aktiv ist, sondern die Methode heißt "IS_DONOR_ACTIVE" und enthält auch gleich die Prüfung.
Weil Du gemerkt hast, dass es nichts bringt, da man in OO im Debugger nichts mehr versteht, OO den Debugger also nahezu unbrauchbar gemacht hat. Damit ist Deine einzige Chance, das Programm direkt zu verstehen und den Fehler abstrakt zu finden.Interessant ist, dass ich mich viel weniger im Debugger bewege, seit ich streng OO programmiere. Bestenfalls gehe ich zu einer bestimmten Stelle, um mir Werte im Debugger anzusehen, aber das "Durchhoppeln" habe ich mir fast komplett abgewöhnt.
Gute Formroutinen tun das auch. Aber hier liegt die Lücke in Deinem Denken. Sie besteht nicht nur darin, dass Du bei jeder Methode genau wissen musst, was sie macht. Schlimmer noch, Du musst bei jedem Objekt wissen, was es macht. Doku, die ausreichend gut ist, gibt es aber kaum. Das fängt schon damit an, dass viele Programmierer gar nicht die realsprachlichen Mittel haben, um ausreichend genau ihre Klassen, Objekte und Methoden zu erklären. Die Mühe machen sie sich ohnehin nicht.Weil ich OO-Coding oft viel klarer und verständlicher finde als Bandwurm-Coding. Gerade die kritisierten vielen kleinen Methoden führen dazu, dass ich viel mehr auf Zusammenhänge achte als auf einzelne Anweisungen, denn Methoden decken quasi Gedankenschritte ab.
Vor allem aber bist Du bei Deinem Ansatz auf Gedeih und Verderb darauf angewiesen, dass die Methoden wie designt funktionieren. Wenn Du einen READ TABLE-Befehl verwendest, dann kannst Du Dich blind darauf verlassen, dass er das macht, was er tun soll. Der ist millionenfach erprobt. Bei einer fremden Methode ist das anders. Ich habe auch in meinen Programmen schon Jahre nach Beginn des Produktivbetriebs noch Fehler gefunden. Das ist ganz normal. Bei TeX haben sie mal versucht, die Software komplett fehlerfrei zu bekommen und für jeden weiteren Bug ansteigende Prämien ausgelobt. Das wurde irgendwann so teuer, dass die Aktion abgebrochen werden musste - obwohl TeX so sauber ist, dass Realsterbliche darin tatsächlich nie einen Fehler finden werden.
Und das ist genau die Stelle, an der Du aufgeschmissen bist: Wenn Du nicht verstehst, was passiert, weil die Methoden des fremden Objektes Bugs enthalten. Und wenn Dich dann der Debugger nicht mehr rettet, weil man menschenlesbar einfach nicht mehr nachvollziehen kann, was genau in solch Programm passiert, dann stehste da! Wenn Methoden die Befehle Deines Programms sind und dann nicht funktionieren, dann arbeitest Du effektiv mit einer kaputten Programmiersprache. Und perfekten Code schreibt nun halt mal niemand.
Ja, so wird OO meistens erklärt. Mit Fahrzeugen und deren Spezialisierungen und "Methoden". Am Ende steht der andere da und sagt: "Das ist alles sehr einleuchtend, aber was, wenn ich kein Flugzeug modellieren, sondern ein Anwendungsprogramm schreiben möchte?"Im Übrigen haben wir es jeden Tag mit Objekten zu tun. Die Kaffeetasse (bekanntlich das erste, was ein Entwickler morgens anfasst und das letzte, was er nachts loslässt), ist nichts anderes als ein Objekt. Bei meiner Kaffeemaschine kümmere ich mich auch nicht darum, welche Bohnenmenge verwendet wird, wieviel Wasser die Maschine braucht, ob die Tasse nicht überläuft, etc. Das macht das Objekt "Kaffeemaschine" ganz von selbst.
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Beitrag
von DeathAndPain (Top Expert / 1964 / 261 /
415
)
»
Wodurch, wie ich kürzlich in einem anderen Zusammenhang gemessen und berichtet habe, die Programmperformance im nicht datenbankzugreifenden Teil Deines Programms um den Faktor 7 sinkt. Aber das nur am Rande; häufig spielt das ja keine Rolle.4byte hat geschrieben:Stimme ich zu. Kann man schön mit Exceptions machen
Das weißt Du eben nicht. Und wenn Du nicht den seltenen Fall sehr guter Dokumentation vor Dir hast, dann weißt Du vor allem auch nicht genau, wie er funktioniert. Beides sind wesentliche Unterschiede zwischen Methodenaufrufen und normalen ABAP-Befehlen.4byte hat geschrieben:Dadurch das du weißt das der Rest funktioniert
Da liegst Du falsch. Im Prozeduralen hast Du eine Aufrufschnittstelle, und da steht die gesamte für den Aufruf relevante Information drin (solange nicht mit globalen Variablen oder gar dem ABAP Memory gearbeitet wird). Das erhöht extrem die Nachvollziehbarkeit der Unterroutine, weil man sieht, was reingeht und was rauskommt. Anhand dessen kann man auch bei unbekanntem Code gut nachvollziehen, was die erwünschte Funktionalität dieser Routine ist und ob sie tut, was sie tun soll.4byte hat geschrieben:Verstehe ich nicht wieso das viele kritisieren. Das hat auch nichts speziell mit OO zu tun. Das kann doch genauso im Prozedualen genutzt werden.Ralf hat geschrieben:Gerade die kritisierten vielen kleinen Methoden führen dazu, dass ich viel mehr auf Zusammenhänge achte als auf einzelne Anweisungen, denn Methoden decken quasi Gedankenschritte ab. Die o. g. Prüfmethode ist so ein Beispiel.
Bei OO hingegen verhält die Methode sich bei einem Aufruf so und beim nächsten mit den gleichen Parametern anders, weil sie auf allerlei versteckte Informationen zugreift, die in "privaten" Feldern und Klassenattributen verborgen sind. Das mag vorteilhaft sein, wenn sie bugfrei arbeitet und man die Soll-Wirkung der Methode genau kennt. Ist aber eins von beiden nicht der Fall, dann legt man sich die Karten zu verstehen, was da passiert. Was man da für zusätzliche Analysezeit reinstecken muss (wenn man es überhaupt schafft), das geht auf keine Kuhhaut.
Prozedural ist ein Stil, bei dem gute Doku wünschenswert ist. OO ist ein Stil, bei dem man ohne gute Doku keine Sonne sieht. In der gelebten Praxis ist gute Doku selten, ob einem das gefällt oder nicht. Damit wird deutlich, welcher der beiden Stile praxistauglicher ist.
Alternativ ein Rückgabewert der Methode, ob die Bearbeitung erfolgreich war oder nicht ? Das verschiebt die Prüfung ja zur aufrufenden Stelle.DeathAndPain hat geschrieben:Wodurch, wie ich kürzlich in einem anderen Zusammenhang gemessen und berichtet habe, die Programmperformance im nicht datenbankzugreifenden Teil Deines Programms um den Faktor 7 sinkt. Aber das nur am Rande; häufig spielt das ja keine Rolle.4byte hat geschrieben:Stimme ich zu. Kann man schön mit Exceptions machen
Einen Vergleich zwischen Methoden und ABAP Befehlen wollte ich nicht an dieser StelleDeathAndPain hat geschrieben:Das weißt Du eben nicht. Und wenn Du nicht den seltenen Fall sehr guter Dokumentation vor Dir hast, dann weißt Du vor allem auch nicht genau, wie er funktioniert. Beides sind wesentliche Unterschiede zwischen Methodenaufrufen und normalen ABAP-Befehlen.
Das stimmt wenn auf Attibute innnerhalb der Methode einfach wahllos zugegriffen wird. Ich definiere die Parameter der Methode immer so, dass die relevanten Infos als IMPORT / CHANGING übergeben werden. So erkenne ich auch was rein / raus geht. Der Zugriff auf "versteckte" Infos kann aber durch Programmierdiziplin unterbunden werden.DeathAndPain hat geschrieben:Da liegst Du falsch. Im Prozeduralen hast Du eine Aufrufschnittstelle, und da steht die gesamte für den Aufruf relevante Information drin (solange nicht mit globalen Variablen oder gar dem ABAP Memory gearbeitet wird). Das erhöht extrem die Nachvollziehbarkeit der Unterroutine, weil man sieht, was reingeht und was rauskommt. Anhand dessen kann man auch bei unbekanntem Code gut nachvollziehen, was die erwünschte Funktionalität dieser Routine ist und ob sie tut, was sie tun soll.
Bei OO hingegen verhält die Methode sich bei einem Aufruf so und beim nächsten mit den gleichen Parametern anders, weil sie auf allerlei versteckte Informationen zugreift, die in "privaten" Feldern und Klassenattributen verborgen sind. Das mag vorteilhaft sein, wenn sie bugfrei arbeitet und man die Soll-Wirkung der Methode genau kennt. Ist aber eins von beiden nicht der Fall, dann legt man sich die Karten zu verstehen, was da passiert. Was man da für zusätzliche Analysezeit reinstecken muss (wenn man es überhaupt schafft), das geht auf keine Kuhhaut.
Nur solange nicht mit globalen Variablen oder ABAP Memory gearbeitet wird. Das sind doch dann genauso versteckte Infos wie Attribute einer Klasse. Sobald eine Unterroutine auf global gehaltene Variablen zugreift, verhält sich doch das ganze was du mir an den Methoden als Nachtteil anhängst. Dann sind zuätzliche Infos in der Routine drin und ich hab genauso wenig Ahnung was die dann bewirkenDa liegst Du falsch. Im Prozeduralen hast Du eine Aufrufschnittstelle, und da steht die gesamte für den Aufruf relevante Information drin (solange nicht mit globalen Variablen oder gar dem ABAP Memory gearbeitet wird).
Das erhöht extrem die Nachvollziehbarkeit der Unterroutine, weil man sieht, was reingeht und was rauskommt. Anhand dessen kann man auch bei unbekanntem Code gut nachvollziehen, was die erwünschte Funktionalität dieser Routine ist und ob sie tut, was sie tun soll.
Wie oft habe ich schon unterroutinen gesehen, die einfach aus auf globale Variablen zugreifen, die an mehreren Stellen verändern und du gar nicht mehr weißt welche Routine wann was wo ändert.
Wo liegt hier der genaue Unterschied beim Verwenden von Attributen? Solange keine Struktur im Programm drin ist, ist es doch egal ob Prozedual oder OO
Eigentlich wollte ich keine Grundsatzdiskussion über Prozedual <> OO anfangen
Wollte einfach die Aussagen von Ralf aus der OO Sicht bestätigen Grüße 4Byte
Es gibt 10 Menschen die binär verstehen 
Beitrag
von DeathAndPain (Top Expert / 1964 / 261 /
415
)
»
Dann biste wieder bei dem, was Ralf vorschwebt (Einsatz einer funktionalen Methode). Aber ja, die finde ich auch vorteilhaft.Alternativ ein Rückgabewert der Methode, ob die Bearbeitung erfolgreich war oder nicht ? Das verschiebt die Prüfung ja zur aufrufenden Stelle.
Aber genau darum geht es bei OO: Methoden wie ABAP-Befehle höherer Abstraktionsklasse verwenden. (Böse Zungen würden sagen, früher gab es das auch schon, und es nannte sich Makro. *duckundweg* *Flame Disclaimer: Diese Aussage war nicht ernst gemeint.*)Einen Vergleich zwischen Methoden und ABAP Befehlen wollte ich nicht an dieser Stelle
Das entspricht aber nicht dem Geist von OO. Nicht ohne Grund sind dort extra "private" Attribute definiert worden. GETTER/SETTER-Methoden sind ja der Urschleim von OO. Auch Ralf schwört darauf, in Objekten Zustände unterzubringen. Und selbstverständlich haben diese Zustände Auswirkungen darauf, wie sich die Methoden der Objekte verhalten. Genau das halte ich für einen wesentlichen Knackpunkt, der OO-Code für alle, die das Programm nicht geschrieben haben, so schwer nachvollziehbar macht. Bei einem fremden OO-Programm muss man beten, dass a) man genau verstanden hat, was die Methoden machen sollen und b) alle Methoden auch das machen, was sie machen sollen (wobei a) und b) auch wieder zusammenhängen, da man bei einem fremden Programm zwischen Bug und Feature nur schwer unterscheiden kann, also nicht weiß, ob das Programmverhalten unerwartet ist, weil man die Sollfunktionalität nicht verstanden hat oder ob ein Programmierfehler vorliegt). Nur exzellente Programmdokumentierung kann das verhindern, und die ist nicht nur selten, sondern auch von den dafür von der SAP gebotenen Werkzeugen her bei OO schlechter gelöst als z.B. bei Funktionsbausteinen.Das stimmt wenn auf Attibute innnerhalb der Methode einfach wahllos zugegriffen wird. Ich definiere die Parameter der Methode immer so, dass die relevanten Infos als IMPORT / CHANGING übergeben werden. So erkenne ich auch was rein / raus geht. Der Zugriff auf "versteckte" Infos kann aber durch Programmierdiziplin unterbunden werden.
Aber bei globalen Variablen und dem ABAP Memory ist man sich seit vielen Jahren weitestgehend einig, dass damit zu arbeiten schlechter Programmierstil ist, der nur in begründeten Ausnahmefällen genutzt werden sollte (gibt wohl Fälle, bei denen es zur Wertübergabe per ABAP Memory aus technischen Gründen kaum Alternativen gibt). Bei OO hingegen ist es der übliche und empfohlene Stil, neben öffentlichen auch mit privaten Attributen zu arbeiten. So gesehen macht ein schlechter prozeduraler Programmierer das Gleiche wie ein guter OO-Programmierer.Nur solange nicht mit globalen Variablen oder ABAP Memory gearbeitet wird. Das sind doch dann genauso versteckte Infos wie Attribute einer Klasse.
Was bei prozeduraler Programmierung schlampert ist, ist bei OO best practice.Das ist nicht schön, aber dennoch kannst Du in solchen Fällen mit Debugger und Watchpoints auf die Suche gehen und hast eine ganz gute Chance, das am Ende zu ergründen. Bei OO kommt der Debugger kaum noch zum Einsatz, wie Du hier im Thread selber gelesen hast. Den wahren Grund dafür gestehen sich die OO-Apologeten jedoch nicht ein. Der besteht nämlich darin, dass Du damit bei OO gar keine Chance hast, weil der Code per Debugger nicht wirklich nachvollziehbar ist. Du hast also nicht andere Werkzeuge, udn es ist auch nicht so, dass Du das Werkzeug nicht mehr brauchst, sondern Du hast einfach ein Werkzeug weniger und stehst im Ernstfall dumm da.Wie oft habe ich schon unterroutinen gesehen, die einfach aus auf globale Variablen zugreifen, die an mehreren Stellen verändern und du gar nicht mehr weißt welche Routine wann was wo ändert.
Hier habe ich mich schlecht ausgedrückt. Ich übergebe explizit die privaten Attribute der Klasse an die MethodenschnittstelleDas entspricht aber nicht dem Geist von OO. Nicht ohne Grund sind dort extra "private" Attribute definiert worden.
Quasi:
Code: Alles auswählen.
me->tue_was( exporting ev_var1 = me->var1
changing cv_var2 = me->var2
)Mhh ich nutze den ganz normal. Dann bin ich einfach zu unerfahren und hab nur zu kleine OO Anwendungen gesehen. Tatsächlich bin ich auch erst seit einem Jahr als Entwickler tätigBei OO kommt der Debugger kaum noch zum Einsatz, wie Du hier im Thread selber gelesen hast. Den wahren Grund dafür gestehen sich die OO-Apologeten jedoch nicht ein. Der besteht nämlich darin, dass Du damit bei OO gar keine Chance hast, weil der Code per Debugger nicht wirklich nachvollziehbar ist.
(Hab ich das schon erwähnt? weiß es grad nimmer 
)Ich arbeite damit. Ich gebe halt bei den Methoden an, dass ich damit arbeiteBei OO hingegen ist es der übliche und empfohlene Stil, neben öffentlichen auch mit privaten Attributen zu arbeiten.
Das ist die erhöhte Abstraktion und da stimme ich dir zuUnd selbstverständlich haben diese Zustände Auswirkungen darauf, wie sich die Methoden der Objekte verhalten. Genau das halte ich für einen wesentlichen Knackpunkt, der OO-Code für alle, die das Programm nicht geschrieben haben, so schwer nachvollziehbar macht.
Bitte lass mich damit in Ruhe(Böse Zungen würden sagen, früher gab es das auch schon, und es nannte sich Makro. *duckundweg* *Flame Disclaimer: Diese Aussage war nicht ernst gemeint.*)
Kann ich mal gar nicht leiden. Wer findet das denn ein gutes Mittel zum entwickeln 
?Grüße 4Byte
Es gibt 10 Menschen die binär verstehen
Beitrag
von DeathAndPain (Top Expert / 1964 / 261 /
415
)
»
Das ist aber nicht üblich, bei jeder einzelnen Methode jedes einzelne interne Attribut, das irgendwas mit der Verarbeitung der Methode zu tun haben könnte, als Exportparameter nach außen zu reichen, um den Programmierer so darauf aufmerksam zu machen, dass es das Ergebnis seiner Methodenausführung beeinflussen könnte. Die normale Antwort des OO-Menschen, so wie ich sie kenne, lautet vielmehr: "Wenn Dich das Attribut interessiert, dann nutze doch die GETTER-Methode, um es Dir zu besorgen!"4byte hat geschrieben:Hier habe ich mich schlecht ausgedrückt. Ich übergebe explizit die privaten Attribute der Klasse an die MethodenschnittstelleDas entspricht aber nicht dem Geist von OO. Nicht ohne Grund sind dort extra "private" Attribute definiert worden.
Quasi:Somit sind beim Aufruf alle relevanten Infos gesetzt und ich sehe was wie genutzt wird.Code: Alles auswählen.
me->tue_was( exporting ev_var1 = me->var1 changing cv_var2 = me->var2 )
Ein Beispiel habe ich ja in meinem Lieblingszitat schon genannt. Debugge mal die Transaktion ME21N und versuche zu verstehen, was da abgeht. Und dann debugge zum Vergleich mal die VA01.Mhh ich nutze den ganz normal. Dann bin ich einfach zu unerfahren und hab nur zu kleine OO Anwendungen gesehen. Tatsächlich bin ich auch erst seit einem Jahr als Entwickler tätigBei OO kommt der Debugger kaum noch zum Einsatz, wie Du hier im Thread selber gelesen hast. Den wahren Grund dafür gestehen sich die OO-Apologeten jedoch nicht ein. Der besteht nämlich darin, dass Du damit bei OO gar keine Chance hast, weil der Code per Debugger nicht wirklich nachvollziehbar ist.
das schaue ich mir mal anEin Beispiel habe ich ja in meinem Lieblingszitat schon genannt. Debugge mal die Transaktion ME21N und versuche zu verstehen, was da abgeht. Und dann debugge zum Vergleich mal die VA01.
Bin halt kein normaler OO-MenschDas ist aber nicht üblich, bei jeder einzelnen Methode jedes einzelne interne Attribut, das irgendwas mit der Verarbeitung der Methode zu tun haben könnte, als Exportparameter nach außen zu reichen, um den Programmierer so darauf aufmerksam zu machen, dass es das Ergebnis seiner Methodenausführung beeinflussen könnte. Die normale Antwort des OO-Menschen, so wie ich sie kenne, lautet vielmehr: "Wenn Dich das Attribut interessiert, dann nutze doch die GETTER-Methode, um es Dir zu besorgen!"
Ist das jetzt ein schlechter Stil ? Ich hab mir mittlerweiter angewöhnt das so zu lösen um die von dir genannten Nachteile ein bisschen abzuschwächen
Es gibt 10 Menschen die binär verstehen
Beitrag
von DeathAndPain (Top Expert / 1964 / 261 /
415
)
»
@black_adept: Bitte nicht zum selbsternannten Moderator aufschwingen und mit riesigen Lettern wichtig machen. Der Autor des OT ist doch zufrieden; sein Problem ist gelöst, also warum sollen wir hier nicht noch etwas schnacken.
Ich denke, dass ein OO-ler das so sehen würde, aber das sollen am besten die OO-Apologeten hier beantworten.4byte hat geschrieben:Ist das jetzt ein schlechter Stil ?
Vergleichbare Themen
7
Antw.
Antw.
1944
Views
Views
2
Antw.
Antw.
5621
Views
Views
Klassen und Methoden als Obsolet markieren
von SaskuAc » 01.02.2018 08:31 • Verfasst in Tips + Tricks & FAQs
von SaskuAc » 01.02.2018 08:31 • Verfasst in Tips + Tricks & FAQs
8
Antw.
Antw.
9649
Views
Views
Architektur von Abap-Klassen (Klassen Attribute)
von snooze » 12.04.2005 12:56 • Verfasst in ABAP Objects®
von snooze » 12.04.2005 12:56 • Verfasst in ABAP Objects®
20
Antw.
Antw.
3794
Views
Views
Globale Klassen oder Lokale Klassen
von ZF_SAPler » 29.11.2022 13:47 • Verfasst in ABAP® für Anfänger
von ZF_SAPler » 29.11.2022 13:47 • Verfasst in ABAP® für Anfänger
9
Antw.
Antw.
5924
Views
Views
Frage die ABAP Experten
Über diesen Beitrag
Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch
Aktuelle Forenbeiträge
Newsletter Anmeldung
Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.Die letzte Ausgabe findest du hier.