Neue Themen als SAP Entwickler
Beitrag
von ralf.wenzel (Top Expert / 3946 / 201 /
281
)
»
Erstens: Du hast ein schlecht gepflegtes Repository 😉 Wenn ich eine bestimmte Funktion suche (beispielsweise das Buchen eines Untersuchungsauftrages für eine Blutspende), dann weiß ich, in welchem Namensraum der Klasse ("irgendwas mit ...." im Namen) oder in welchem Paket ich suchen muss. Und wenn ich das nicht weiß, weiß ich, welcher Entwickler das vorwiegend macht und dann frag ich den (siehe unten).DeathAndPain hat geschrieben: ↑05.09.2024 18:46Ich schreibe auch öfter mal eine globale Klasse, weil ich mir denke "das kann man bestimmt noch mal wieder gebrauchen". Aber wenn ich es ein halbes Jahr später wirklich mal wieder brauche, dann habe ich in vielen Fällen längst vergessen, dass ich solch Klasse mal geschrieben habe. Ich staune immer wieder, was für (von mir selber stammende) nützliche Klassen und Methoden ich immer mal wieder finde und denke mir dann: "Das hättest Du in Programm xy gut gebrauchen können, wenn Du Dich daran erinnert hättest."Ralf hat geschrieben:Also, ich schreibe fast alles ins DDIC, weil ich immer wieder gestaunt habe, wie viel sich wiederverwenden lässt, wenn man es nur abstrakt genug hält.
Und Du schreibst alles und seinen Hund ins DDIC und behauptest, dass Du da den Überblick behältst und die Methoden alle wiederfindest, wenn Du mal vor einem ähnlichen Problem stehst?!? Das kann ich mir nicht wirklich vorstellen.
Zweitens: Ich mache vorwiegend geschlossene Projekte, das macht es mir einfacher.
Beim Blutspendedienst saßen wir mit fünf Leuten in einem Raum. Da weiß man, wer was macht und wenn ich einen Untersuchungsauftrag buchen muss, weiß der Untersuchungsauftrag-Entwickler, welche Lösungen es schon gibt und welche nicht.
Jetzt im international verteilten Projekt nehmen wir dafür Zoom. "Gibt es schon ein Interface, das .... macht" und entweder meldet sich einer weil er weiß, dass es das gibt oder nicht gibt oder es meldet sich keiner, dann schreibt man es sich selbst.
Ich möchte erreichen, dass ein Objekt sich an einer ALV-Buttonleiste anmelden kann. Dazu brauche ich ein Interface zum subscriben - ich füge dem Objekt also die Eigenschaft hinzu, sich an- und abmelden zu können. Wenn ich das Interface an eine Methode übergebe, hat das Objekt den Typ des Interfaces (was dazu führt: Egal wie das Objekt aussieht, ich kann es übergeben, weil es die notwendige Eigenschaft (also das notwendige Interface) hat).DeathAndPain hat geschrieben: ↑05.09.2024 18:46Bitte nenne mal ein praktisches Beispiel, damit die Sache konkret wird.Ralf hat geschrieben:Nein, Interfaces benutze ich, um einer Klasse bestimmte Eigenschaften zu geben.
Und warum wird die Funktion dann so versteckt und nicht bei jedem Syntaxcheck oder zumindest bei der Aktivierung durchlaufen?DeathAndPain hat geschrieben: ↑05.09.2024 18:46Bei Rechnern im unteren dreistelligen Megahertzbereich, wie sie üblich waren, als es Funktionsgruppen schon gegeben hat, mag das - möglicherweise - mal ein Thema gewesen sein, aber heutige Maschinen lachen sich über die Rechenlast für solch Syntaxprüfung doch schlapp.
Erweiterte Programmprüfung -> Programmübergreifende Prüfung. Da und NUR da wird geprüft, ob den Funktionsbausteinen auch typgerechte Felder zugewiesen werden.DeathAndPain hat geschrieben: ↑05.09.2024 18:46So richtig habe ich nicht verstanden, welche Syntaxprüfung Du hier genau meinst. Die wenn man die Funktionsgruppe kompiliert?Ralf hat geschrieben:Darum wird die "tiefe Prüfung" bei der Syntaxprüfung von Funktionsgruppen nicht durchlaufen - weil es zu lange dauert, das ganze Paket aufzuschnüren und darin herumzusuchen.
....auch das Fenster teilen (sogar in der SAPGUI), dann habe ich immer den Definition- und den Implementation-Teil im Blick. Ohne Scrollen, etc.DeathAndPain hat geschrieben: ↑05.09.2024 18:46Ich hingegen empfinde vor allem Medienbrüche als schlimm. Wenn ich rasch eine Parametrisierung nachschauen muss, während ich in der Methode tippe, dann kann ich
Den Besitz von Schusswaffen haben die N*z*s verboten, weil sie keinen Bock hatten auf ein bewaffnetes und damit wehrhaftes Volk. In freien Ländern wie den USA ist der Waffenbesitz weitestgehend liberalisiert, weil man keine Angst vor wehrhaften Bürgern hat. Dass es Leute gibt, die sich dabei selbst ins Knie schießen, wird bewusst in Kauf genommen -- das stützt genau meine Argumentation.DeathAndPain hat geschrieben: ↑05.09.2024 18:46Der Prozentsatz ist aber durchaus bedeutsam. Wenn man den Leuten allen Pistolen geben würde, dann würden sicherlich auch viele verantwortungsbewusst damit umgehen. Aber doch ein geringerer Prozentsatz als bei Messern. Also verbietet man die Pistolen.
In Deutschland braucht man demnächst einen Transportsafe, wenn man sich ein Obstmesser kaufen will. Aber das ist ein anderes Thema.
Das sollte es sowieso sein - egal bei welchen Entwicklungsobjekten. Aber selbst die SAP macht das nicht mehr, auch egal bei welchen Entwicklungsobjekten. Mir geht einer ab, wenn ich sehe, wie gut das BAL dokumentiert ist. Ehrlich. Sensationelle Doku.DeathAndPain hat geschrieben: ↑05.09.2024 18:46Gleichwohl habe ich ja nicht gesagt, dass ich instanziierte Klassen verbieten möchte. Vielleicht aber wäre es gut, wenn die Pflege der Doku zum Objekt ein Pflichtfeld sein würde.
Ich kenne eine ganze Horde von Entwicklern, die das Quatsch finden und auf globale Variablen SCHWÖREN, weil das so schön einfach ist. Keine Newbies, sondern gestandene Leute mit 20, 30 Jahren Erfahrung.DeathAndPain hat geschrieben: ↑05.09.2024 18:46Bei prozeduralen Programmen hat sich zumindest mal die Verhaltensweise weitgehend durchgesetzt, globale Variablen zu meiden.
Das ist dasselbe was ich bei prozeduralen Programmen oft beobachte und ich bin der erste, der sich zwei Stunden zu solchen Leuten setzt und denen erklärt, dass das Mist ist.DeathAndPain hat geschrieben: ↑05.09.2024 18:46Was die Leute da machen, hat mit Zuständen, die das Objekt beschreiben sollen, meist nicht viel zu tun. Es wird einfach aus Bequemlichkeit mit klassenglobalen Feldern gearbeitet und fertig.
Insofern gebe ich dir absolut recht: OO ist keine Rechtfertigung für schlechtes Programmieren.
Danke, das ist sehr wohl angekommen.DeathAndPain hat geschrieben: ↑05.09.2024 18:46Das habe ich mir schon immer gedacht. Insofern Applaus für dieses Statement.Ralf hat geschrieben:Reine Setter- und Gettermethoden entsprechen eigentlich nicht im Stand der Technik. Denn hierzu muss man wissen, wofür die einzelnen (oft privaten) Attribute in der Klasse notwendig sind. Das sollte den Aufrufe aber eigentlich schon nicht interessieren.
Ralf *der toll findet, dass man hier so schön und sachlich diskutieren kann - mein ausgesprochenes Kompliment an die Mitdiskutanten. Das war hier mal anders 😉 Da kann ich mich an ganze Schlachten erinnern, die ich hier geschlagen habe 😉 In diesem Zusammenhang möchte ich noch auf mein Posting im Off-Topic aufmerksam machen.
PS: Ob der, der den Thread gestartet hat, hier noch mitliest? 😉
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Beitrag
von DeathAndPain (Top Expert / 1961 / 261 /
415
)
»
Das ist mir immer noch zu abstrakt. Ich habe keine Vorstellung davon, was genau Du da in der SE24 an der Klasse änderst.Ralf hat geschrieben:Ich möchte erreichen, dass ein Objekt sich an einer ALV-Buttonleiste anmelden kann. Dazu brauche ich ein Interface zum subscriben - ich füge dem Objekt also die Eigenschaft hinzu, sich an- und abmelden zu können. Wenn ich das Interface an eine Methode übergebe, hat das Objekt den Typ des Interfaces (was dazu führt: Egal wie das Objekt aussieht, ich kann es übergeben, weil es die notwendige Eigenschaft (also das notwendige Interface) hat).
Welche Funktion genau? Erweiterte Programmprüfung -> Programmübergreifende Prüfung? Wie gesagt, Funktionsbausteine werden stets mit dynamischer Namenangabe gerufen. Den Namen kann man für Bausteine, bei denen die Namen konkret in Hochkommata angegeben werden, zwar statisch herleiten, aber das ist halt etwas, was der Compiler nicht macht, sondern nur jenes zusätzliche Prüfprogramm der SAP.Ralf hat geschrieben:Und warum wird die Funktion dann so versteckt und nicht bei jedem Syntaxcheck oder zumindest bei der Aktivierung durchlaufen?
Du machst Dir keine Vorstellung, wie lang manche meiner Zeilen sind. 😁 Und rechts kommt ja (in Eclipse) auch öfter mal ein Fenster hoch, das Platz braucht, etwa beim Verwendungsnachweis.Ralf hat geschrieben:....auch das Fenster teilen (sogar in der SAPGUI), dann habe ich immer den Definition- und den Implementation-Teil im Blick. Ohne Scrollen, etc
Das halte ich für ein Gerücht. Meines Wissens sind private Schusswaffen in den meisten Ländern, gerade in Europa, verboten. Das ist mitnichten ein deutsches Phänomen. Im Gegenteil ist es eine US-amerikanische Spezialität, dass sie dort erlaubt sind. Das hat historische Gründe: Das Second Amendment geht auf die Siedlerzeit des Wilden Westens zurück. Da hast Du irgendwo in den USA Deine Farm gehabt, und der nächste Nachbar war 50 km entfernt. Wenn da was war, konntest Du nicht einfach die Polizei rufen; die gab es nämlich nicht (allenfalls einen Sheriff in der nächsten Stadt 100 km entfernt). Aus dieser Zeit gibt es das Stand-Your-Ground-Prinzip, demzufolge Du Waffen besitzen und Deinen Grund und Boden damit selber verteidigen darfst. (Ob das reicht, wenn die Banditenhorde in Deiner Farm einfällt, ist nochmal eine andere Frage.)Ralf hat geschrieben:Den Besitz von Schusswaffen haben die N*z*s verboten, weil sie keinen Bock hatten auf ein bewaffnetes und damit wehrhaftes Volk. In freien Ländern wie den USA ist der Waffenbesitz weitestgehend liberalisiert, weil man keine Angst vor wehrhaften Bürgern hat.
Die USA waren seinerzeit also gar nicht in der Lage, ihre Bürger mit Staatsgewalt sinnvoll zu beschützen, dazu war zu viel Fläche zu dünn besiedelt. Aus dieser Zeit geht dieses Waffenrecht hervor, was von den Amis daher als traditionelles Grundrecht angesehen wird. Ob diese Auffassung heutzutage noch sinnvoll ist, ist eine andere Frage.
Solange sie nur in ihr eigenes Knie schießen, dürften die wenigsten damit ein Problem haben. Wie es tatsächlich läuft, kannst Du gerade dieser Tage in der Tagesschau sehen.Ralf hat geschrieben:Dass es Leute gibt, die sich dabei selbst ins Knie schießen, wird bewusst in Kauf genommen -- das stützt genau meine Argumentation.
Auf der anderen Seite bin ich Verschwörungstheoretiker und misstraue insofern dem Staat zutiefst. Von daher hege ich durchaus Sympathien für Deinen Standpunkt. Aber wer Zweifel an der Integrität des deutschen Staates und seiner Politiker hat, wird ja ganz schnell als Antidemokrat diffamiert.
Ich beobachte sowas eher selten. Die eine oder andere globale Variable wird zuweilen verwendet, ja, aber nicht exzessiv. Mein Eindruck ist, dass das auch eine Folge der ungarischen Notation ist. Ich halte diese zwar für ähnlich überflüssig wie Du, aber sie wurde den Leuten nun mal eingebleut, und damit ist in den Köpfen drin, zwischen global und lokal zu unterscheiden. Zu viele GV_ will niemand in seinem Code haben; da fühlen die Leute sich anscheinend unwohl. Ich denke zwar, dass da viel Gewohnheit bzw. erlernte Schemen und wenig tatsächliches Verständnis dahinter ist, aber im Ergebnis sind die allermeisten Variablen doch lokal.Ralf hat geschrieben:Ich kenne eine ganze Horde von Entwicklern, die das Quatsch finden und auf globale Variablen SCHWÖREN, weil das so schön einfach ist. Keine Newbies, sondern gestandene Leute mit 20, 30 Jahren Erfahrung.
...
Das ist dasselbe was ich bei prozeduralen Programmen oft beobachte und ich bin der erste, der sich zwei Stunden zu solchen Leuten setzt und denen erklärt, dass das Mist ist.
Hab Dank!Ralf hat geschrieben:Ralf *der toll findet, dass man hier so schön und sachlich diskutieren kann - mein ausgesprochenes Kompliment an die Mitdiskutanten.
Na ja. Ich kann mich erinnern, dass es hier vor Jahren mal einen Spinner gegeben hat, der sich in den Kopf gesetzt hatte Dich rauszuekeln. Der hat aber vom ganzen Rest des Forums die Meinung gesagt bekommen und ist dann recht schnell selber verschwunden.Ralf hat geschrieben:Das war hier mal anders
Beitrag
von ralf.wenzel (Top Expert / 3946 / 201 /
281
)
»
Ich füge das Interface hinzu und programmiere die Methoden aus.DeathAndPain hat geschrieben: ↑05.09.2024 22:04Das ist mir immer noch zu abstrakt. Ich habe keine Vorstellung davon, was genau Du da in der SE24 an der Klasse änderst.
Dann ist dein Bildschirm zu schmal 😉 Aber ich habe eine wahnsinnige Abneigung gegen lange Zeilen. Darum schreibe ich z. B.DeathAndPain hat geschrieben: ↑05.09.2024 22:04Du machst Dir keine Vorstellung, wie lang manche meiner Zeilen sind. 😁 Und rechts kommt ja (in Eclipse) auch öfter mal ein Fenster hoch, das Platz braucht, etwa beim Verwendungsnachweis.
LOOP AT ...
ASSIGNING FIELD-SYMBOL....
USING KEY ...
WHERE...
was ich deutlich lesbarer finde als
LOOP AT ... ASSINGING FIELD-SYMBOL... USING KEY... WHERE ... in einer Zeile, gerade wenn die WHERE-Bedingung aus mehreren Teilen besteht.
Ich kenne Schweizer, die zum hiesigen Waffenrecht nur den Kopf schütteln.
Was ich dieser Tage sehe, ist:DeathAndPain hat geschrieben: ↑05.09.2024 22:04Solange sie nur in ihr eigenes Knie schießen, dürften die wenigsten damit ein Problem haben. Wie es tatsächlich läuft, kannst Du gerade dieser Tage in der Tagesschau sehen.
Heute hat ein Islamist in München rumgeballert. Zum Glück hat er auf die Polizei geschossen, die kann sich verteidigen. In Berlin wurde ein Radfahrer erschossen, der wohl in eine Clan-Auseinandersetzung geraten war. Dann gab es vor einer Weile einen Messerangriff in Aken, ein Stadtfest wurde abgebrochen und über Solingen brauche ich gar nicht zu reden.
Keines der zivilen Opfer konnte sich verteidigen, weil man bald für das Mitführen einer Nagelschere eine Sondergenehmigung braucht.
Ich bin Segler ohne eigenes Boot. Heißt: Ich muss mein Zeugs bei mir tragen, wenn ich zum Segeln gehe. Da ist ein Einhandmesser ("eine Hand fürs Boot") elementar, weil ich nur zwei Hände habe. Dabei stehe ich mit einem Bein außerhalb des Gesetzes, wenn mich einer dabei erwischt. Schon deshalb, weil ich am Hbf umsteige auf dem Weg zum Boot und mich dabei sogar in einer Waffenverbotszone bewege.
Ein Messer ist primär ein Werkzeug wie ein Hammer oder ein Schraubendreher - nicht primär eine Waffe wie eine Pistole.
So geht es mir seit Corona auch, insbesondere seit dieser Tage rauskommt, was "Verschwörungstheoretiker", "Querdenker" und "Rechte" schon lange behaupten: Dass wir systematisch belogen wurden.DeathAndPain hat geschrieben: ↑05.09.2024 22:04Auf der anderen Seite bin ich Verschwörungstheoretiker und misstraue insofern dem Staat zutiefst.
Ich hab mir sowas schon gedacht. Die Pointe ist: Der wollte mich nicht vertreiben, sondern mir zeigen, wer der Bessere ist und dass ich keine Ahnung habe. Weil: Er war mein Auftraggeber im Projekt, wir saßen beim gleichen Kunden am gleichen Schreibtisch einander gegenüber (wenn ich vor Ort gearbeitet habe) 😉 Das macht das Ganze noch witziger.DeathAndPain hat geschrieben: ↑05.09.2024 22:04Na ja. Ich kann mich erinnern, dass es hier vor Jahren mal einen Spinner gegeben hat, der sich in den Kopf gesetzt hatte Dich rauszuekeln. Der hat aber vom ganzen Rest des Forums die Meinung gesagt bekommen und ist dann recht schnell selber verschwunden.Ralf hat geschrieben:Das war hier mal anders
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Genau das meinte ich mit - die Beispiele in Klammern sind auch keine (klassischen) Property-Setter.ralf.wenzel hat geschrieben: ↑05.09.2024 18:29Um ein eBook in den Zustand „gelesen“ zu setzen, ist es schlüssiger, die Methode „read_ebook( )“ aufzurufen statt eine Methode „set m_flag_read( )...
Stimmt. Als Rahmeneinstieg wäre es tatsächlich sinnvoll, um das zu verhindern bzw. weitgehend einzuschränken und erinnert mich direkt auch an den Einstiegspunkt bei C#, Java usw. 🥳DeathAndPain hat geschrieben: ↑05.09.2024 18:46Erstens kannst Du dann in START-OF-SELECTION lokale Felder definieren, die nicht global und damit in den gerufenen Untermethoden nicht vorhanden sind (saubere Kapselung).
Dein Beispiel wiederum passt dann jedoch nicht mehr, weil du da nun weitere Methoden in die Rahmenklasse einbaust und damit hantierst (abgesehen davon, dass es so wie es da steht, nicht funktioniert). Stattdessen müsste es mMn (und ich greife auf mein Beispiel zurück) da wie folgt aussehen:
Code: Alles auswählen.
class lcl_user definition.
... usw. ...
class lcl_main definition.
public section.
class-methods: execute.
endclass.
class lcl_main implementation.
method execute.
data(user) = new lcl_user( p_user ).
cl_some_mailing_helper=>send_immediately(
i_content_as_html = |<em>Aloha monsieur { user->get_salutation( ) },</em><br><br>please pay 3 Bitcoins to { cl_hax0r=>get_bitcoin_addy( ) } within 24 hours or I will make your passwords public. See:<br><br>{ cl_some_converter=>table_to_html_list( user->get_password_history( ) ) }<br><br>Yours truly,<br>Holgerino| )
i_recipients = user->get_mail_address( )
).
" oder einfacher:
cl_some_mailing_helper=>send_immediately(
i_content_as_html = cl_hax0r=>create_ransom_note( i_victim = user )
i_recipients = user->get_mail_address( )
).
" ... usw. ...
endmethod.
endclass.
parameters p_user type xubname.
start-of-selection.
lcl_main=>execute( ).
Da sind wir uns einig - weswegen ich dort den Parameter auch (wie beschrieben: "und dabei auch direkt Klasse A an den Constructor der Klasse B weiterreichen, usw.") nicht weglassen würde.DeathAndPain hat geschrieben: ↑05.09.2024 18:46Vor allem, wenn dann die Methoden gerufen werden, die den von dir mit "... anzeigen, per Mail senden, Log schreiben, whatever ..." beschriebenen Teil implementieren, ist dann user_used_passwords sicherlich auch nicht Bestandteil der Parameterschnittstelle. Sowas finde ich hässlich und unsauber.
Wenn ein Event-Handler eine andere Klasse benötigt (->Abhängigkeit, Dependency), sollte man diese Klasse dem Constructor des Event-Handlers mitgeben, damit er diese als PRIVATE Property ablegen und innerhalb der Event-Methoden nutzen kann.DeathAndPain hat geschrieben: ↑05.09.2024 18:46Tatsächlich sind die Methoden meiner obenstehenden LC-Klasse bis auf MAIN alle privat. Ausnahmen gibt es allenfalls dann, wenn durch Dynprotechnologie weitere Aufrufe von außerhalb der Klasse erfolgen müssen (beispielsweise bei einem Doppelklick ins erzeugte ALV, wo dann die Event-Handler-Klasse des ALVs meine lokale Klasse rufen muss).
Ganz einfache Lösung: Code-Review vor bzw. bei Abnahme. Die Frage ist also: Warum wird das nicht gemacht?DeathAndPain hat geschrieben: ↑05.09.2024 18:46Viele Leute schreiben schlechten Code, ob es unsereins gefällt oder nicht.
Zuletzt geändert von tar am 05.09.2024 23:13, insgesamt 2-mal geändert.
Beitrag
von ralf.wenzel (Top Expert / 3946 / 201 /
281
)
»
Aus vielfältigen Gründen: Weil es ziemlich teuer ist (ich bin ja schon froh, bei einem Kunden zu sein, der Unit-Tests und Dokumentation begrüßt und bezahlt!). Weil sich das Unternehmen nicht auf einheitliche Regeln einigen kann. Weil kein Entwickler Bock drauf hat, das zu machen (sich in den Code Externer einzuarbeiten).tar hat geschrieben: ↑05.09.2024 22:38Ganz einfache Lösung: Code-Review vor bzw. bei Abnahme. Die Frage ist also: Warum wird das nicht gemacht?DeathAndPain hat geschrieben: ↑05.09.2024 18:46Viele Leute schreiben schlechten Code, ob es unsereins gefällt oder nicht.
Außerhalb von SAP scheint das aber ziemlich üblich zu sein.
Zu den einheitlichen Regeln: Ich hatte mal einen Code-Reviewer, der mich wahnsinnig gemacht hat. Zwei Beispiele: Ihm gefiel nicht wie ich eine Methode geschrieben habe. Er hat mir gesagt wie er es gern hätte und ich habe es umgeschrieben. Zwei Tage später wollte er das geänderte reviewen und hat genau das kritisiert, was ich geändert habe. Mein Hinweis, das sei seine Anweisung gewesen, beantwortete er mit dem Hinweis: Ja, vorgestern wollte ich das so, heute nicht mehr.
Das andere: Derselbe Reviewer hat eine Klasse von mir kritisiert. Während er so vor sich hin doziert, landet er über einen Methodenaufruf in seiner eigenen Klasse und erklärt, mir, wie schlecht ich das alles gemacht hätte. Irgendwann kam ich dazwischen und wies ihn darauf hin "Dir ist aber klar, dass die ganze Klasse von dir ist?". Da war schnell Ruhe 😂
Ralf
Folgende Benutzer bedankten sich beim Autor ralf.wenzel für den Beitrag (Insgesamt 3):
tar • black_adept • DeathAndPain
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von ralf.wenzel (Top Expert / 3946 / 201 /
281
)
»
Nein. Wenn er den gemeint haben sollte, dann reden wir über unterschiedliche Personen.
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von black_adept (Top Expert / 4103 / 128 /
945
)
»
Das ist eigentlich ein Standardproblem mit dem Vergessen bzw. nicht Wiederfinden. Ich helfe mir inzwischen damit, dass ich einen Sack voll thematisch gegliederter Utilityklassen habe mit einem definierten Namen, die alle in einem Paket liegen. Z.B. ZCL_BC_ALV_UTILITIES, ZCL_BC_SELSCREEN_UTILITIES, ... und abschließend für den ganzen Müll, den man zwar hier und dort braucht aber für den es sich nicht lohnt eine thematisch eigene Klasse zu bauen ZCL_BC_VARIOUS_UTILITIES.DeathAndPain hat geschrieben: ↑05.09.2024 18:46Ich schreibe auch öfter mal eine globale Klasse, weil ich mir denke "das kann man bestimmt noch mal wieder gebrauchen". Aber wenn ich es ein halbes Jahr später wirklich mal wieder brauche, dann habe ich in vielen Fällen längst vergessen, dass ich solch Klasse mal geschrieben habe. Ich staune immer wieder, was für (von mir selber stammende) nützliche Klassen und Methoden ich immer mal wieder finde und denke mir dann: "Das hättest Du in Programm xy gut gebrauchen können, wenn Du Dich daran erinnert hättest."Ralf hat geschrieben:Also, ich schreibe fast alles ins DDIC, weil ich immer wieder gestaunt habe, wie viel sich wiederverwenden lässt, wenn man es nur abstrakt genug hält.
Und Du schreibst alles und seinen Hund ins DDIC und behauptest, dass Du da den Überblick behältst und die Methoden alle wiederfindest, wenn Du mal vor einem ähnlichen Problem stehst?!? Das kann ich mir nicht wirklich vorstellen.
Folgende Benutzer bedankten sich beim Autor black_adept für den Beitrag:
ralf.wenzel
Beitrag
von black_adept (Top Expert / 4103 / 128 /
945
)
»
Aufgrund der Art und Weise wie SAP Dynpros und Selektionsbildschirme handhabt, ist es halt nötig/sehr praktisch ein paar klar begrenzte globale, im Programm definierte Variablen zu haben.tar hat geschrieben: ↑05.09.2024 22:38Den Parameter P_USER kriegt man meines Wissens nach leider nicht auch noch in den Rahmen (könnte man zwar als Methoden-Parameter deklarieren, aber ändert nichts an dessen "globaler" Verfügbarkeit). Auch Select-Options und sämtliche PUBLIC-statischen Deklarationen blieben "global" verfügbar, u.a. weil ABAP leider keine Klassendeklarationen innerhalb von Klassen erlaubt (sowie auch keine Hilfsmethoden innerhalb von Methoden usw.).
Dazu gehören halt Parameter und SelOpts. Hier habe ich in meinem Programmklasse einen Typ, der die Felder des Selektionsbilds spiegelt
Code: Alles auswählen.
types: begin of lts_selections,
t_r_matnr type range of mara-matnr,
t_r_werks type range of werks_d,
...
field1_sinnvoll_benamt , " z.B. für Radiobuttons, Checkboxen oder Parameter
end of lts_selectionsWeiterhin ist es bei Dynpros (die du, tar, ja so gar nicht magst ) an diversen Stellen deutlich einfacher mit via TABLES definierten Strukturen zu arbeiten als allen anderen Alternativen, zumal man für den Feldtransport im Dynpro ins Programm einfach globale Variablen ( die auch statische Attribute einer Klasse sein können ) benötigt, es sei denn man will unbedingt anders arbeiten als die Programmiersprache das vorsieht.
Beitrag
von ralf.wenzel (Top Expert / 3946 / 201 /
281
)
»
Wer mag schon Dynpros? Ich finde das Konstrukt grausig.
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von black_adept (Top Expert / 4103 / 128 /
945
)
»
Ja - man hätte da in den Jahren mal überarbeiten und schöner machen können, zumal ja alle Objekte auf dem Screen so wie früher in VB Formularen fast schon objektorientiert sind.ralf.wenzel hat geschrieben: ↑06.09.2024 12:01Wer mag schon Dynpros? Ich finde das Konstrukt grausig.
Ralf
Aber dadurch hat man halt ein genormtes Look&Feel welches halt sehr, sehr langweilig daherkommt, aber nichtdestotrotz ein recht gutes Handling bietet.
Beitrag
von DeathAndPain (Top Expert / 1961 / 261 /
415
)
»
Das kann man auch bei abstrakten Klassen machen. :-)Ralf hat geschrieben:Ich füge das Interface hinzu und programmiere die Methoden aus.
Da suche ich mir immer sinnvolle Kompromisse. In dem Fall würde ich tatsächlich bis WHERE in einer Zeile schreiben, aber mit AND oder OR angebundene Zusatzbedingungen dann bündig hinter dem WHERE in weitere Zeilen schreiben. Die WHERE-Bedingung ist ja das Einzige, was bei solch LOOP nicht immer so leicht lesbar ist.Ralf hat geschrieben:Dann ist dein Bildschirm zu schmal 😉 Aber ich habe eine wahnsinnige Abneigung gegen lange Zeilen. Darum schreibe ich z. B.
LOOP AT ...
ASSIGNING FIELD-SYMBOL....
USING KEY ...
WHERE...
was ich deutlich lesbarer finde als
LOOP AT ... ASSINGING FIELD-SYMBOL... USING KEY... WHERE ... in einer Zeile, gerade wenn die WHERE-Bedingung aus mehreren Teilen besteht.
Generell macht mir auch der Pretty Printer zu viele Zeilenumbrüche. Warum bei dem Aufruf einer Subroutine z.B. das Schlüsselword EXPORTING komplett alleine in einer Zeile stehen soll, ist mir schleierhaft. Ich schreibe das so:
Code: Alles auswählen.
meine_methode( EXPORTING parameter1 = whatever
parameter2 = that_too
IMPORTING parameter3 = what_you_get
parameter4 = what_you_also_get ).Die Schweizer sind Nachzügler, was das Abschaffen von Bürgerrechten angeht. Aber häppchenweise gleichen die sich auch dem Rest Europas an.Ralf hat geschrieben:Ich kenne Schweizer, die zum hiesigen Waffenrecht nur den Kopf schütteln.
Das meinte ich.Ralf hat geschrieben:Was ich dieser Tage sehe, ist:
Heute hat ein Islamist in München rumgeballert. Zum Glück hat er auf die Polizei geschossen, die kann sich verteidigen. In Berlin wurde ein Radfahrer erschossen, der wohl in eine Clan-Auseinandersetzung geraten war. Dann gab es vor einer Weile einen Messerangriff in Aken, ein Stadtfest wurde abgebrochen und über Solingen brauche ich gar nicht zu reden.
Wäre es besser, wenn sie zurückschießen könnten und es dann auf der Straße eine ausgewachsene Schießerei geben würde? Klar, bei solch Terrorist wäre das ein Vorteil. Aber Du weißt, wie viele Spinner es auch in der Normalbevölkerung gibt. Wenn die alle eine Waffe einstecken haben, wenn sie unterwegs sind, dann wird es jede Menge Schießereien geben, die es sonst nicht gegeben hätte.Ralf hat geschrieben:Keines der zivilen Opfer konnte sich verteidigen, weil man bald für das Mitführen einer Nagelschere eine Sondergenehmigung braucht.
Die von Dir genannten Nachrichten sind ja letztlich nicht die Konsequenz des deutschen Waffenrechts, sondern der Entwicklung, die mit den Worten: "Wir schaffen das" ihren Anfang genommen hat. (Na ja, eigentlich schon deutlich früher, aber zu diesem Zeitpunkt ist es endgültig aus dem Ruder gelaufen.)
Ich bin an dieser Stelle kein Rechtsexperte, vermute aber, dass das okay ist, wenn sich das Messer gut verpackt in Deinem Rucksack befindet, also nicht einsatzbereit mitgeführt wird. Das halte ich für einen wesentlichen Unterschied. Genau wie Du beim Autofahren auch ein Handy eingeschaltet in Deinem Rucksack oder im Kofferraum haben darfst, aber nicht griffbereit auf der Mittelkonsole.Ralf hat geschrieben:Ich bin Segler ohne eigenes Boot. Heißt: Ich muss mein Zeugs bei mir tragen, wenn ich zum Segeln gehe. Da ist ein Einhandmesser ("eine Hand fürs Boot") elementar, weil ich nur zwei Hände habe. Dabei stehe ich mit einem Bein außerhalb des Gesetzes, wenn mich einer dabei erwischt. Schon deshalb, weil ich am Hbf umsteige auf dem Weg zum Boot und mich dabei sogar in einer Waffenverbotszone bewege.
Dazu könnte ich unendlich viel sagen. Das Deutlichste ist aus meiner Sicht aber immer noch der Umstand, dass im Oktober/November 2019 eine große Veranstaltung abgehalten worden ist, bei der der weltweite Ausbruch eines Coronavirus simuliert worden ist, komplett mit simulierten Nachrichten, Konferenzrunden, in denen diskutiert wurde, welche Maßnahmen man ergreift und was man der Bevölkerung erzählt usw. Das war einen Monat vor Ausbruch des echten Corona!!! Da kann mir keiner erzählen, dass das Zufall ist, und das ist auch keine Fake News; die Veranstaltung hat eine Homepage, auf der sie ganz offiziell dokumentiert ist. Dort kann man auch erkennen, wer das veranstaltet hat. Das sind die einschlägigen Namen wie die Melinda& Bill Gates Foundation, die John-Hopkins-Universität oder auch das Weltwirtschaftsforum unter Klaus Schwab.Ralf hat geschrieben:So geht es mir seit Corona auch, insbesondere seit dieser Tage rauskommt, was "Verschwörungstheoretiker", "Querdenker" und "Rechte" schon lange behaupten: Dass wir systematisch belogen wurden.
Dazu der Umstand, dass der Fischmarkt, auf dem das Virus angeblich "entstanden" sein soll, nur 500 m entfernt von einem Biolabor der höchsten Sicherheitsklasse 4 ist. Solche Labore gibt es in der ganzen Welt nur eine Handvoll. Damit ist allerdings noch nicht klar, ob das Virus von dort stammt oder nur dort freigesetzt worden ist, um es den Chinesen in die Schuhe zu schieben. Beides halte ich für denkbar.
Dann die drei Präsidenten unterschiedlicher Länder (Tansania, Madagascar und Haiti), die offen Zweifel an Corona geäußert und sich geweigert haben, Lockdowns über ihre Bevölkerungen zu verhängen und Impfkampagnen zu starten. Alle drei sind dann ganz plötzlich und überraschend bei bester Gesundheit gestorben (nicht an Corona, das wird noch nicht mal behauptet). Bei Haiti hat man es auf Bandenkriminalität geschoben, bei den anderen beiden Ländern waren es halt rätselhafte Tode. Ihre jeweiligen Nachfolger haben dann sofort die Lockdowns verhängt.
Immerhin kann man heute wieder in Foren über sowas diskutieren, ohne dass sofort der Inhalt wegzensiert und das Account mit einer Sperre belegt wird wegen "Fake News". Das war 2020/21 anders. Der damalige niedersächsische Innenminister hat ja sogar gefordert, das Verbreiten von Fake News unter Strafe zu stellen. Das hätte natürlich die Errichtung eines Wahrheitsministeriums erfordert, das festlegt, welche Aussagen wahr sind und daher geäußert werden dürfen und welche nicht. Daher ist diese Forderung nicht weiterverfolgt worden; da hat wohl doch der eine oder andere sich überlegt, was das verfassungsrechtlich bedeuten würde. Geschadet hat es der Karriere jenes Innenministers jedoch nicht: Heute ist er Bundesverteidigungsminister und gilt als beliebtester Politiker Deutschlands. Das Volk ist dumm (und lässt sich Sonderschulden als "Sondervermögen" verkaufen).
Aber ich schweife ab.
Natürlich funktioniert es. Ich baue alle meine Reports genau so. Das würde ich ganz schnell merken, wenn das nicht funktionieren würde. Wobei ich natürlich nur ein Codefragment geboten habe, das z.B. den DEFINITION-Block der Klasse nicht enthält.tar hat geschrieben:Dein Beispiel wiederum passt dann jedoch nicht mehr, weil du da nun weitere Methoden in die Rahmenklasse einbaust und damit hantierst (abgesehen davon, dass es so wie es da steht, nicht funktioniert).
Was sollten geschachtelte Klassen da auch bringen? Alle Dynprofelder (also insbesondere auch die des Selektionsbildes) sind klassische programmglobale Variablen. Damit sind sie überall im Programm verfügbar, egal wie sehr Du da auch schachtelst.tar hat geschrieben:Den Parameter P_USER kriegt man meines Wissens nach leider nicht auch noch in den Rahmen (könnte man zwar als Methoden-Parameter deklarieren, aber ändert nichts an dessen "globaler" Verfügbarkeit). Auch Select-Options und sämtliche PUBLIC-statischen Deklarationen blieben "global" verfügbar, u.a. weil ABAP leider keine Klassendeklarationen innerhalb von Klassen erlaubt (sowie auch keine Hilfsmethoden innerhalb von Methoden usw.).
Gerade mit Blick auf das Selektionsbild finde ich das aber auch nicht sonderlich dramatisch, da Selektionsbildfelder sich nach START-OF-SELECTION nicht mehr zu ändern pflegen. Zum einen kann man sie insofern wie Konstanten betrachten, zum anderen ist auch nie unklar, wo ihre Werte herkommen, auch wenn sie irgendwo in einer tief geschachtelten Methode vorfindet. Damit haben sie den wesentlichen Nachteil globaler Variablen verloren. Was bleibt, ist der Bequemlichkeitsvorteil. Wenn ich beispielsweise auf dem Selektionsbild ein Datumsfeld STICHTAG vorgebe, an dem sich alle SELECT-Befehle in meinem Programm orientieren (WHERE BEGDA <= STICHTAG AND ENDDA >= STICHTAG), dann brauche ich diesen STICHTAG nicht Ebene für Ebene durch meine lokalen Routinenschnittstellen durchzureichen und kann ihn überall nutzen, und dem Leser ist dennoch stets klar, was das für ein Wert ist und wo er herkommt.
Gleichwohl bin ich eurer Meinung, dass die Dynprotechnologie gut abgehangen ist und nicht mehr als modern eingeschätzt werden kann. Es ist aber gut, dass es SAPGUI-Bilder gibt und nicht nur HTML-basiertes Fiori-Geraffel.
Es wäre aber schön, wenn zumindest mal dieser Feldtransport komplett automatisch in Echtzeit erfolgen würde (und zwar in beide Richtungen) und man nicht mehr mit Funktionsbausteinen wie DYNP_VALUES_READ herumhampeln müsste.black_adept hat geschrieben:zumal man für den Feldtransport im Dynpro ins Programm einfach globale Variablen ( die auch statische Attribute einer Klasse sein können ) benötigt
Ich bin der Meinung, dass sie zu ihrer Zeit eine durchaus vernünftige Technologie gewesen sind. Sie haben sich nur halt aus Kompatibilitätsgründen seit damals quasi nicht mehr verändert und wirken heutzutage wie komplett aus der Zeit gefallen.Ralf hat geschrieben:Wer mag schon Dynpros? Ich finde das Konstrukt grausig.
Das schätze ich auch sehr an Dynpros und halte es für ein Erfolgsgeheimnis der SAP. Die Frage ist nur, ob es nicht möglich wäre, Fensterbilder mit identischem Aussehen (also Aufrechterhaltung des Look&Feel) mit modernen Hilfsmitteln zu gestalten, also gewissermaßen Newdynpros. Der Anwender muss gar nicht unterscheiden können, ob es sich um ein altes oder neues Dynpro handelt, weil die Unterschiede zu 100% unter der Haube angesiedelt sind. Für unsereins wäre es aber bedeutend angenehmer.black_adept hat geschrieben:Aber dadurch hat man halt ein genormtes Look&Feel welches halt sehr, sehr langweilig daherkommt, aber nichtdestotrotz ein recht gutes Handling bietet.
Derlei Neuerungen fände ich bedeutend produktiver, als mit einem neuen "Quartz"-Theme, das in seiner Anfangszeit auch noch alle Naselang abgestürzt ist, alle Farbe aus dem Bildschirm zu nehmen und damit die optische Orientierung auf dem Bild bedeutend zu erschweren. Ich verstehe nicht, dass manche Leute sich freiwillig dafür entscheiden.
Beitrag
von ralf.wenzel (Top Expert / 3946 / 201 /
281
)
»
Der Witz ist, dass man mehrere Interfaces in einer Klasse haben kann. Je nach Bedarf hat man also den einen oder anderen Typ.DeathAndPain hat geschrieben: ↑06.09.2024 21:28Das kann man auch bei abstrakten Klassen machen. :-)Ralf hat geschrieben:Ich füge das Interface hinzu und programmiere die Methoden aus.
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Mir ist nicht klar, wieso so oft(!) Interfaces um Klassen herum gebaut werden. Ich selbst brauche sie in den seltensten Fällen (ich erinnere mich an genau 1 und das war in C#) und eben - beim Thema Modaldialog - habe ich explizit darauf verzichtet, gerade um flexibler zu sein, was die Implementierung verfügbarer Event-Methoden angeht. Bei einem Interface heißt es hingegen: alles oder nichts, was das Coding unnötig aufbläht. Klar: bei einem Interface hat man eben ein klar definiertes Interface (wer hätte es gedacht), aber wann benötigt man tatsächlich mal ein klassenübergreifendes - und dann täte es eben auch eine vererbbare Klasse. 😕
Kennt eigentlich jemand den technischen Hintergrund, warum man in ABAP in einer Klasse keine weiteren Klassen typisieren kann, die systemweit genutzt werden könnten, aber sonstige öffentliche Typisierungen?
Kennt eigentlich jemand den technischen Hintergrund, warum man in ABAP in einer Klasse keine weiteren Klassen typisieren kann, die systemweit genutzt werden könnten, aber sonstige öffentliche Typisierungen?
Folgende Benutzer bedankten sich beim Autor tar für den Beitrag:
DeathAndPain
Vergleichbare Themen
0
Antw.
Antw.
2300
Views
Views
OO-Themen die in anderen Threads OT sind
von black_adept » 23.08.2018 09:01 • Verfasst in ABAP Objects®
von black_adept » 23.08.2018 09:01 • Verfasst in ABAP Objects®
10
Antw.
Antw.
15278
Views
Views
Suche Videotutorials zu folgenden Themen
von Up4Anything » 02.03.2011 14:01 • Verfasst in Tutorials & Cookbooks
von Up4Anything » 02.03.2011 14:01 • Verfasst in Tutorials & Cookbooks
2
Antw.
Antw.
3456
Views
Views
Aktuelle Themen / Forschungstrends im SAP Bereich
von OnkelSAP » 28.03.2011 12:35 • Verfasst in SAP - Allgemeines
von OnkelSAP » 28.03.2011 12:35 • Verfasst in SAP - Allgemeines
18
Antw.
Antw.
6209
Views
Views
4
Antw.
Antw.
9888
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
CL_GUI_ALV_GRID - Zeilen auf Read-Only / Editierbar schalten
vor 3 Tagen von a-dead-trousers 5 / 1511
vor 3 Tagen von a-dead-trousers 5 / 1511
Newsletter Anmeldung
Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.Die letzte Ausgabe findest du hier.
Aktuelle Forenbeiträge
CL_GUI_ALV_GRID - Zeilen auf Read-Only / Editierbar schalten
vor 3 Tagen von a-dead-trousers 5 / 1511
vor 3 Tagen von a-dead-trousers 5 / 1511