Kommunikation von Klassen und Methoden

Getting started ... Alles für einen gelungenen Start.
24 Beiträge • Vorherige Seite 2 von 2 (current)
24 Beiträge Vorherige Seite 2 von 2 (current)

Re: Kommunikation von Klassen und Methoden

Beitrag von DeathAndPain (Top Expert / 1795 / 213 / 396 ) »
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.
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.
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.
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.
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.
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.

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.
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.
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?"

gesponsert
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten


Re: Kommunikation von Klassen und Methoden

Beitrag von DeathAndPain (Top Expert / 1795 / 213 / 396 ) »
4byte hat geschrieben:Stimme ich zu. Kann man schön mit Exceptions machen :)
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:Dadurch das du weißt das der Rest funktioniert
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:
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.
Verstehe ich nicht wieso das viele kritisieren. Das hat auch nichts speziell mit OO zu tun. Das kann doch genauso im Prozedualen genutzt werden.
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.

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.

Re: Kommunikation von Klassen und Methoden

Beitrag von 4byte (Specialist / 124 / 37 / 35 ) »
DeathAndPain hat geschrieben:
4byte hat geschrieben:Stimme ich zu. Kann man schön mit Exceptions machen :)
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.
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: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.
Einen Vergleich zwischen Methoden und ABAP Befehlen wollte ich nicht an dieser Stelle :roll:
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.
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.
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.
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 bewirken :roll:
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. :roll:
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 8)

Eigentlich wollte ich keine Grundsatzdiskussion über Prozedual <> OO anfangen :D Wollte einfach die Aussagen von Ralf aus der OO Sicht bestätigen :D

Grüße 4Byte
Es gibt 10 Menschen die binär verstehen :)

Re: Kommunikation von Klassen und Methoden

Beitrag von DeathAndPain (Top Expert / 1795 / 213 / 396 ) »
Alternativ ein Rückgabewert der Methode, ob die Bearbeitung erfolgreich war oder nicht ? Das verschiebt die Prüfung ja zur aufrufenden Stelle.
Dann biste wieder bei dem, was Ralf vorschwebt (Einsatz einer funktionalen Methode). Aber ja, die finde ich auch vorteilhaft.
Einen Vergleich zwischen Methoden und ABAP Befehlen wollte ich nicht an dieser 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.*)
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.
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.
Nur solange nicht mit globalen Variablen oder ABAP Memory gearbeitet wird. Das sind doch dann genauso versteckte Infos wie Attribute einer Klasse.
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. :P Was bei prozeduraler Programmierung schlampert ist, ist bei OO best practice.
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. :roll:
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.

Re: Kommunikation von Klassen und Methoden

Beitrag von 4byte (Specialist / 124 / 37 / 35 ) »
Das entspricht aber nicht dem Geist von OO. Nicht ohne Grund sind dort extra "private" Attribute definiert worden.
Hier habe ich mich schlecht ausgedrückt. Ich übergebe explizit die privaten Attribute der Klasse an die Methodenschnittstelle
Quasi:

Code: Alles auswählen.

me->tue_was(  exporting  ev_var1  = me->var1
 changing cv_var2 = me->var2                         
)
Somit sind beim Aufruf alle relevanten Infos gesetzt und ich sehe was wie genutzt wird.
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.
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ätig :D (Hab ich das schon erwähnt? weiß es grad nimmer :twisted: )
Bei OO hingegen ist es der übliche und empfohlene Stil, neben öffentlichen auch mit privaten Attributen zu arbeiten.
Ich arbeite damit. Ich gebe halt bei den Methoden an, dass ich damit arbeite :P
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.
Das ist die erhöhte Abstraktion und da stimme ich dir zu :up:
(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.*)
Bitte lass mich damit in Ruhe :x Kann ich mal gar nicht leiden. Wer findet das denn ein gutes Mittel zum entwickeln :mrgreen: ?

Grüße 4Byte
Es gibt 10 Menschen die binär verstehen :)

Re: Kommunikation von Klassen und Methoden

Beitrag von DeathAndPain (Top Expert / 1795 / 213 / 396 ) »
4byte hat geschrieben:
Das entspricht aber nicht dem Geist von OO. Nicht ohne Grund sind dort extra "private" Attribute definiert worden.
Hier habe ich mich schlecht ausgedrückt. Ich übergebe explizit die privaten Attribute der Klasse an die Methodenschnittstelle
Quasi:

Code: Alles auswählen.

me->tue_was(  exporting  ev_var1  = me->var1
 changing cv_var2 = me->var2                         
)
Somit sind beim Aufruf alle relevanten Infos gesetzt und ich sehe was wie genutzt wird.
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!"
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.
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ätig :D (Hab ich das schon erwähnt? weiß es grad nimmer :twisted: )
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.

Re: Kommunikation von Klassen und Methoden

Beitrag von black_adept (Top Expert / 3943 / 105 / 886 ) »
Antworten, die nicht zum OT gehören sondern die OO-Diskussion betreffen, bitte in diesem Thread weiterführen
live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de

Re: Kommunikation von Klassen und Methoden

Beitrag von 4byte (Specialist / 124 / 37 / 35 ) »
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.
das schaue ich mir mal an :)
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!"
Bin halt kein normaler OO-Mensch :D

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 :roll:
Es gibt 10 Menschen die binär verstehen :)

Re: Kommunikation von Klassen und Methoden

Beitrag von DeathAndPain (Top Expert / 1795 / 213 / 396 ) »
@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.
4byte hat geschrieben:Ist das jetzt ein schlechter Stil ?
Ich denke, dass ein OO-ler das so sehen würde, aber das sollen am besten die OO-Apologeten hier beantworten.

Vergleichbare Themen

7
Antw.
1371
Views
Kommunikation zwischen zwei Klassen
von abapnewbie » 30.08.2020 15:30 • Verfasst in ABAP Objects®
2
Antw.
3719
Views
Klassen und Methoden als Obsolet markieren
von SaskuAc » 01.02.2018 08:31 • Verfasst in Tips + Tricks & FAQs
8
Antw.
8179
Views
Architektur von Abap-Klassen (Klassen Attribute)
von snooze » 12.04.2005 12:56 • Verfasst in ABAP Objects®
20
Antw.
973
Views
Globale Klassen oder Lokale Klassen
von ZF_SAPler » 29.11.2022 13:47 • Verfasst in ABAP® für Anfänger
9
Antw.
4612
Views
Lokale Klassen in globalen Klassen
von ralf.wenzel » 20.04.2020 22:55 • Verfasst in ABAP Objects®

Aktuelle Forenbeiträge

Zwischensumme Adobe Forms
vor 2 Tagen von Lucyalison 1 / 64
Interne Tabelle
vor 5 Tagen von black_adept 2 / 133
MaLo-Checker in ABAP
vor einer Woche von A6272 6 / 254

Newsletter Anmeldung

Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.
Die letzte Ausgabe findest du hier.
Details zum Versandverfahren und zu Ihren Widerrufsmöglichkeiten findest du in unserer Datenschutzerklärung.

Aktuelle Forenbeiträge

Zwischensumme Adobe Forms
vor 2 Tagen von Lucyalison 1 / 64
Interne Tabelle
vor 5 Tagen von black_adept 2 / 133
MaLo-Checker in ABAP
vor einer Woche von A6272 6 / 254

Unbeantwortete Forenbeiträge

Zwischensumme Adobe Forms
vor 2 Tagen von Lucyalison 1 / 64
Group Items auf einer Filterbar
vor einer Woche von Bright4.5 1 / 107
tRFC Transaktionen SM58
vor 4 Wochen von A6272 1 / 140