Umfrage zu euren Erfahrungen mit ATC

Alles rund um die Sprache ABAP®: Funktionsbausteine, Listen, ALV
36 Beiträge • Vorherige Seite 3 von 3 (current)
36 Beiträge Vorherige Seite 3 von 3 (current)

Re: Umfrage zu euren Erfahrungen mit ATC

Beitrag von DeathAndPain (Top Expert / 1952 / 259 / 413 ) »
Ralf hat geschrieben:
DeathAndPain hat geschrieben:Soweit die Theorie. Menschliche Psyche funktioniert aber anders.
Mit der Einstellung könntest du die gesamte Wissenschaft und Forschung auf der Welt zumachen.
Wieso das denn?!? Die Wissenschaftler der Welt arbeiten doch nicht alle in demselben Labor! Wenn Du allerdings als WM (wissenschaftlicher Mitarbeiter) die Arbeitsmethoden Deines Profs oder anderer WMs, die am Nebentisch arbeiten, offen kritisierst, dann kannst Du durchaus ähnliche Effekte erleben, ja.
Ralf hat geschrieben:
DeathAndPain hat geschrieben:Das ist ein Lehrer, der hat eine pädagogische Ausbildun
Das macht jeder andere, der einen Vortrag hält, auch.
Eine pädagogische Ausbildung haben? Das halte ich für ein Gerücht.
Ralf hat geschrieben:
DeathAndPain hat geschrieben:Etwas anderes ist es, wenn ein Schüler zum Lehrer geht und ihm im Auditor-Stil sagt, dass er seine Unterrichtsmethoden nicht in Ordnung findet und dass er der Meinung ist, der Lehrer solle seinen Unterrichtsstil in dieser und jener Richtung umstellen.
Hab ich gemacht, 9. Klasse. Und mir damit nicht den Lehrer zum Feind gemacht, sondern die anderen Schüler.
Das sind zwei verschiedene Paar Schuhe, die sich freilich nicht ausschließen. Du wirst wohl irgendwas gefordert haben, was für die Schüler Mehrarbeit bedeutet hat, was diese Dir übel genommen haben.

Wie der Lehrer darüber gedacht hat, wissen wir nicht. Das muss er Dir ja nicht erzählt haben (bzw. er hat Dir nur den politisch korrekten, also den nicht mimosenhaften Teil davon erzählt). Selbst wenn Du Deine Kritik nur in Form von Empfehlungen vorgebracht haben solltest (das, worüber wir in dem Thread hier diskutieren, ist sogar noch einen Zacken schärfer), gilt doch die Regel, dass Ratschläge auch Schläge sind, bzw. das Sprichwort: "Gib nie einen Rat. Der Weise braucht ihn nicht, und der Narr verwirft ihn. Aber beide nehmen ihn übel."
Ralf hat geschrieben:Abgesehen davon, dass einem Schüler der Auditor-Stil nicht zusteht, weil er kein Auditor ist. Bei einem Auditor weiß ich: Was der sagt, ist erstmal Gesetz!
Bei einem formalen Audit schon. Aber so, wie ich diesen Thread bislang verstanden habe, reden wir nicht von einem formalen Audit (bei dem der Auditor in aller Regel ein Externer ist), sondern von einer Nutzung des ATC-Tools für ein Vier-Augen-Prinzip beim Programmieren: Mitarbeiter A kontrolliert den Code von Mitarbeiter B und umgekehrt (z.B. weil sie die beiden einzigen Entwickler im Hause sind). Mitarbeiter A hat bestimmte Schwerpunkte, die er wichtig findet, Mitarbeiter B andere. Du kannst zwar versuchen, Regeln aufzustellen, was kritikwürdig ist und was nicht, aber wenn das so einfach wäre, dann bräuchte man das zweite Augenpaar nicht, sondern könnte den ATC vollautomatisch den Code kontrollieren lassen (Code Inspector-style).

Glaub mir: Auch wenn man sich bei Kritikpunkten zusammensetzt und sich im Gespräch auf Lösungen einigt (wozu man am Arbeitsplatz ja letztlich gezwungen ist), bleibt doch rein emotional beim Codeurheber in aller Regel das negative Gefühl des Kritisiertwordenseins zurück. Und an Emotionen erinnert man sich weit länger als an Sachfakten; das ist eine meines Wissens biologisch begründete Tatsache.

ich würde das gerne mal sehen, wie Du Daniels Code auditierst und umgekehrt, jeder dem anderen die Umsetzung seiner Kritikpunkte aufzwingt und ihr anschließend produktiv weiter zusammenarbeitet. :-D
DeathAndPain hat geschrieben:Aber es entsteht keine Liebe zum UnterDRÜCKer. :-D
Wenn ich von meiner Frau und meinen Kindern geliebt werde, reicht mir das. Kollegen und Kunden sollen mich respektieren, nicht lieben.
Die Möglichkeit zu dieser Einstellung ist ein Freelancern vorbehaltener Luxus.
Ralf hat geschrieben:
DeathAndPain hat geschrieben:Das mache ich auch zuweilen. Ob es Zeit spart, bin ich mir aber nicht sicher, denn manchmal kommt die Lösung (so wie in Deinem Fall), in vielen Fällen guckt der aber auch nur drauf, lässt sich den Sachverhalt erklären, rätselt und kapituliert am Ende
Ah, weil die Wahrscheinlichkeit besteht, dass es schiefgeht, versuchst du es erst gar nicht?
Nein. Wie von mir beschrieben, versuche ich es durchaus gelegentlich. Ich habe nur dargelegt, dass ich mir nicht sicher bin, ob es sich in der Bilanz lohnt. In aller Regel findet man die Antwort ja auch alleine, wenn man genug Zeit und Energie reinsteckt. Wenn nun in 30% der Fällen der andere einem helfen kann und man diese Zeit einspart, in 70% der Fälle der andere es aber nicht schafft und man durch die initiale Erklärung, das folgende gemeinsame Grübeln und fruchtlose Diskussionen nochmal die gleiche Zeit oben drauflegt, dann lässt sich festhalten, dass sich das Fragen im statistischen Mittel nicht lohnt und daher im Einzelfall auch nicht anzuraten ist (negativer Erwartungswert im Glücksspiel). Ich bin nicht sicher, ob es tatsächlich so schlecht aussieht. Rein gefühlsmäßig will ich das aber nicht ausschließen.

Wir reden dabei von Problemen, die komplex genug sind, dass sie nicht mit einem raschen Zuruf über den Tisch beantwortet werden können. Und wenn man einen Kollegen fragt, dann will man auch nicht unhöflich sein. Ich habe das schon häufig erlebt, dass ich schon in der ersten Minute nach Fragestellung sagen konnte, der weiß es auch nicht, da habe ich ja noch mehr Durchblick, da kommt nix bei raus. Dann ist man aber schon im Gespräch gefangen und kann den anderen mit seinen Vorschlägen (die man alle längst durchdacht hat oder die von mangelndem Verständnis des Sachverhalts zeugen) nicht rasch abwürgen, sondern muss zumindest so lange diskutieren, bis er selber merkt, dass er nicht wird helfen können. Erst dann hat man wieder einen sozial verträglichen Bailout Point. Damit kann man eine ganze Menge Zeit verbrennen!

Es ist also nicht so, dass man im Zweifel immer fragen sollte. Es lohnt durchaus, seine Chancen vorher ein bisschen abzuwägen.
Ralf hat geschrieben:
DeathAndPain hat geschrieben:Du weißt aber nicht, was sie im stillen Kämmerlein über Dich gedacht oder in der Pause über Dich geredet haben. Und wie Dein Arbeitsklima sich entwickelt hätte, wenn Du als ihr Kollege in dem Laden Deinen Arbeitsalltag der nächsten Jahre hättest verbringen müssen.
Ach, weißt du.. Ich war Stotterer auf einer Ruhrgebietshauptschule, Hauptschüler in einer Familie von lauter hochbegabten Akademikern, die ganze Stadt wusste dass mein Stiefvater meine Mutter im Suff verprügelt hat. Und ich beschränke mich explizit auf den nicht so schlimmen Teil meiner Lebensgeschichte. Wenn du SO eine Lebensgeschichte hast, ist dir Getuschel egal.
Ich war als Schüler auch Außenseiter und habe gelernt damit umzugehen. Das heißt aber nicht, dass das erstrebenswert wäre oder dass ich nicht zu schätzen wüsste, dass es jetzt anders ist und ich mich einer positiven Teamathmosphäre erfreue.

Davon abgesehen haben Mitschüler kaum Einfluss auf Deine weitere Laufbahn. Versaust Du es Dir hingegen mit Kollegen, dann ist das Team belastet, und das kann früher oder später personelle Konsequenzen haben. Wirst Du als Brennpunkt der Teambelastung identifiziert, dann bist Du mit Deinem Arbeitsplatz auch naheliegender Ansatzpunkt zur Lösung des Problems für den Chef.

Ich habe mir mal eine Mir-doch-egal-Haltung erlaubt, als ich mich geweigert habe, in die Gewerkschaft einzutreten und jeden Monat 1% meines Gehalts zum Machterhalt des (typischerweise auch in der Gewerkschaft aktiven) Betriebsrats beizusteuern. Dabei habe ich eben jene Macht gewaltig unterschätzt. Trotz größter Anstrengungen meines Vorgesetzten, mich zu halten, hat mich das nach einigen Jahren den Job gekostet.
Ralf hat geschrieben:
DeathAndPain hat geschrieben:So läuft das in der Realität.
Aber nur in der Software-Entwicklung. Kein Mensch würde die QM bei einer Schraube in Frage stellen, nur weil kein Geld dafür da ist.
Wenn Du wüsstest, was ich schon für Schrauben gesehen habe... mitnichten haben die alle eine hochwertige Qualitätssicherung.
Ralf hat geschrieben:Es liegt an uns, den Leuten klarzumachen, dass wir keine Script-Kiddies sind.
Die Haltung kannst Du gegenüber Endanwendern und deren wissensgleichen Vorgesetzten vertreten. Bei Deinesgleichen aber hast Du nicht von vornherein den Nimbus des fachlich Überlegenen.
Ralf hat geschrieben:Schon der Quatsch, dass Klassen mit CL und Interfaces mit IF anfangen, zeigt, dass die, die sich das ausgedacht haben, nicht viel von Softwareentwicklung verstehen. Das ist in anderen Sprachen (soweit ich das überblicken kann) "sehr unüblich", um das mal vorsichtig formulieren.
Interfaces sind so ziemlich das einzige OO-Element in ABAP, das ich nie so richtig begriffen habe. Von der Theorie her schon: Man definiert einen Parametersatz, auf den man sich dann in Klassen etc. beziehen kann. Aber oft genug sehe ich im Code, wie Interfaces gerufen werden und grübele, welche der vielen Implementierungen dann gezogen wird - und woher das System weiß, welche davon es ziehen soll. Trotz mehrerer Anläufe habe ich noch keine Erklärung von Interface-Nutzung in ABAP gesehen, die ich so weit verstanden hätte, dass es bis in die Praxis hineinreicht.
Ralf hat geschrieben:Sorry, aber solange ein Artikel im SPIEGEL oder in einem Buch vom Layout her anders aussieht als dein Quelltext, kannst du hier nicht mit "menschlichem Lesefluss" argumentieren.
Beim SPIEGEL wäre die richtige Argumentation "für Propagandazwecke", aber das steht auf einem anderen Blatt.
Ralf hat geschrieben:Gerade bei technischen Texten liegt Lesbarkeit sehr wohl im Auge des Betrachters. Darum finde ich zum Beispiel Leerzeilen zwischen Anweisungen der Lesbarkeit förderlich (weil viele Anweisungen mehrzeilig sind und ich so sofort sehe, wo die Anweisung anfängt und endet), bei einem Kunden wurde ich aufgefordert, alle unnötigen Leerzeilen zu vermeiden, weil das den Quelltext verlängert - was er unübersichtlich findet. Er will soviel Quelltext auf einen Blick sehen wie möglich.
In diese Richtung tendiere ich auch, allerdings nur, solange es nicht zu Lasten der Lesbarkeit geht. Leerzeilen können Codeblöcke gut strukturieren und sind von daher hilfreich. Was mich am PP nervt, sind verschenkte Zeilen, die nicht der Lesbarkeit dienen. Ein typisches Beispiel sind CALL FUNCTION-Aufrufe. Da finde ich es optisch optimal, wenn der erste EXPORTING-Parameter rechts neben dem Schlüsselwort EXPORTING steht und die übrigen dann bündig darunter. Die übrigen Blöcke (IMPORTING, TABLES, EXCEPTIONS) ebenso. Das Schlüsselwort in eine eigene Zeile zu stellen, wie der PP es macht, dient Null der Lesbarkeit, ganz im Gegenteil. Der Code wird länger UND schlechter lesbar.

Zum Glück ist der PP konfigurierbar. Ich nutze ihn viel - aber nur, um meinen Gesamtcode in Großschreibung zu setzen 3.1i-style. :-D Ein Graus für Kollegen, aber jedem das Seine. ;-)
ewx hat geschrieben:Der prettyprinter ist ein fester Bestandteil der ABAP-Programmierung.
"Fest" stimmt nur bedingt. Wie schon erwähnt ist der PP konfigurierbar. Man kann in gewissem Umfang einstellen, was er tun soll und was nicht. Wenn Daniel mit Großschreibung klarkommt ( :-D ), dann würde ihn mein PP nicht stören.
ewx hat geschrieben:Ein quelltext, bei dem durch Anwenden des PP die Verständlichkeit „zerstört“ wird, ist definitiv nicht gut.
Wie sieht so ein Quelltext denn aus?
ewx hat geschrieben:Es ist also wichtig, zu erkennen, „wer in dem Kapitel ermordet wird“. Die Formatierung des quelltextes hilft dabei. Eine „extravagante“ Formatierung ist eher hinderlich.
Warum? "Extravagant" muss ja nicht "schlecht lesbar" bedeuten. Im Gegenteil kann es bedeuten, dass die Lesbarkeit trickreich heraufgesetzt worden ist.
Ralf hat geschrieben:Der Funktionsbaustein zerschneidet mir nicht das Coding, ich kann die Methode direkt an einer funktionalen Operandenposition einsetzen (quasi wie ein CONV). In meinen Augen ist das lesbarer, in seinen schon deshalb Quatsch, weil es in einer Methode steht.
Ja, das ist etwas, was ich auch bedaure, dass Funktionsbausteinaufrufe nicht funktional gestaltet werden können. Dafür braucht man für eine Methode halt jede Menge zeitraubenden Overhead, bevor man überhaupt damit anfangen kann, den eigentlichen Nutzcode zu schreiben. Das lohnt sich nur, wenn es genug Aufrufe gibt, die von der funktionalen Darstellung profitieren.

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


Re: Umfrage zu euren Erfahrungen mit ATC

Beitrag von ralf.wenzel (Top Expert / 3935 / 200 / 281 ) »
DeathAndPain hat geschrieben:Eine pädagogische Ausbildung haben? Das halte ich für ein Gerücht.
Nein, sich bedanken, wenn man ihn auf einen Fehler aufmerksam macht.
DeathAndPain hat geschrieben:Wie der Lehrer darüber gedacht hat, wissen wir nicht. Das muss er Dir ja nicht erzählt haben (bzw. er hat Dir nur den politisch korrekten, also den nicht mimosenhaften Teil davon erzählt).
Wir haben das intensiv diskutiert.
DeathAndPain hat geschrieben:Bei einem formalen Audit schon. Aber so, wie ich diesen Thread bislang verstanden habe, reden wir nicht von einem formalen Audit (bei dem der Auditor in aller Regel ein Externer ist), sondern von einer Nutzung des ATC-Tools für ein Vier-Augen-Prinzip beim Programmieren: Mitarbeiter A kontrolliert den Code von Mitarbeiter B und umgekehrt (z.B. weil sie die beiden einzigen Entwickler im Hause sind). Mitarbeiter A hat bestimmte Schwerpunkte, die er wichtig findet, Mitarbeiter B andere. Du kannst zwar versuchen, Regeln aufzustellen, was kritikwürdig ist und was nicht, aber wenn das so einfach wäre, dann bräuchte man das zweite Augenpaar nicht, sondern könnte den ATC vollautomatisch den Code kontrollieren lassen (Code Inspector-style).
Du hast es leider nicht verstanden: Es gibt Regeln, von der Entwicklungsleiter stellt Regeln auf und die MA kontrollieren sich gegenseitig auf Einhaltung (es sei denn, der Entwicklungsleiter oder ein Auditor machen das selbst). Zweifelsfälle werden diskutiert.
DeathAndPain hat geschrieben:Glaub mir: Auch wenn man sich bei Kritikpunkten zusammensetzt und sich im Gespräch auf Lösungen einigt (wozu man am Arbeitsplatz ja letztlich gezwungen ist), bleibt doch rein emotional beim Codeurheber in aller Regel das negative Gefühl des Kritisiertwordenseins zurück.
Meine Güte, was sind das für Mimosen, die man nicht kritisieren darf, ohne dass sie emotional daran zerbrechen???
DeathAndPain hat geschrieben:ich würde das gerne mal sehen, wie Du Daniels Code auditierst und umgekehrt, jeder dem anderen die Umsetzung seiner Kritikpunkte aufzwingt und ihr anschließend produktiv weiter zusammenarbeitet. :-D
Das geht nicht, weil der Code völlig verschiedenen Philosophien folgt. Eigentlich ist schon das ein Unding auf einem System. Aber weil die Philosophien, unter denen wir arbeiten, so unterschiedlich sind, macht ein Audit keinen Sinn.
DeathAndPain hat geschrieben:
DeathAndPain hat geschrieben:Aber es entsteht keine Liebe zum UnterDRÜCKer. :-D
Wenn ich von meiner Frau und meinen Kindern geliebt werde, reicht mir das. Kollegen und Kunden sollen mich respektieren, nicht lieben.
Die Möglichkeit zu dieser Einstellung ist ein Freelancern vorbehaltener Luxus.
Professioneller Umgang mit Kollegen ist Freelancern vorbehalten?
DeathAndPain hat geschrieben:Interfaces sind so ziemlich das einzige OO-Element in ABAP, das ich nie so richtig begriffen habe. Von der Theorie her schon: Man definiert einen Parametersatz, auf den man sich dann in Klassen etc. beziehen kann. Aber oft genug sehe ich im Code, wie Interfaces gerufen werden und grübele, welche der vielen Implementierungen dann gezogen wird - und woher das System weiß, welche davon es ziehen soll. Trotz mehrerer Anläufe habe ich noch keine Erklärung von Interface-Nutzung in ABAP gesehen, die ich so weit verstanden hätte, dass es bis in die Praxis hineinreicht.
Ui, das ist ein großes "Loch". Das ist leider nicht mal so eben erklärt, sonst würde ich das gern machen. Aber eine Interfaceimplementierung hängt ja an einer Objektinstanz. Welche das ist, hängt halt von den Umständen ab (das ist ja u. a. der Zweck des Interfaces). Du hast zum Beispiel den Vorgang einer Blutspende, an dem sich alle Elemente registrieren: Die Blutspende-Probenröhrchen, die physische Blutspende selbst, der Spender, etc. Alle implementieren ein subsribe/unsubsribe-Interface, mit dem sie sich am Vorgang registrieren. Mit einer ID, die natürlich vom Subscriber abhängt (eine Blutspenden-Nummer sieht anders aus als eine Röhrchen-ID). Mal so als Beispiel. Ja, das ist etwas abstrakt, aber so hast du halt unterschiedlichste Elemente mit unterschiedlichsten Eigenschaften, die unter einem "Sammler" hängen können.
DeathAndPain hat geschrieben:
Ralf hat geschrieben:Der Funktionsbaustein zerschneidet mir nicht das Coding, ich kann die Methode direkt an einer funktionalen Operandenposition einsetzen (quasi wie ein CONV). In meinen Augen ist das lesbarer, in seinen schon deshalb Quatsch, weil es in einer Methode steht.
Ja, das ist etwas, was ich auch bedaure, dass Funktionsbausteinaufrufe nicht funktional gestaltet werden können. Dafür braucht man für eine Methode halt jede Menge zeitraubenden Overhead, bevor man überhaupt damit anfangen kann, den eigentlichen Nutzcode zu schreiben. Das lohnt sich nur, wenn es genug Aufrufe gibt, die von der funktionalen Darstellung profitieren.
Eine statische Klasse zu erzeugen ist mehr Overhead als eine Funktionsgruppe zu erzeugen?


Ralf
Bild
Ralf Wenzel Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
PublikationenUngarische NotationXing

Re: Umfrage zu euren Erfahrungen mit ATC

Beitrag von DeathAndPain (Top Expert / 1952 / 259 / 413 ) »
Nein, sich bedanken, wenn man ihn auf einen Fehler aufmerksam macht.
Weil die Höflichkeit es gebietet. Das sagt nichts darüber aus, wie er es emotional - oft unterbewusst - verarbeitet.
Wie der Lehrer darüber gedacht hat, wissen wir nicht. Das muss er Dir ja nicht erzählt haben (bzw. er hat Dir nur den politisch korrekten, also den nicht mimosenhaften Teil davon erzählt).
Wir haben das intensiv diskutiert.
Auf der Sachebene. Was Du nicht siehst, ist die emotionale Ebene, die als Meta-Ebene darüber liegt und sehr wohl auch im Unterbewussten verborgen sein kann, dem Kritisierten also noch nicht einmal bewusst, gleichwohl aber wirksam ist.

Deswegen meinte ich ja, dass Du bei einer Untersuchung von Schülern, die ihre Lehrer kritisieren, im Vergleich zu solchen, die lieber die Schnauze halten, bei ersteren im Mittel (!) bessere Zeugnisnoten sehen würdest. Dabei denke ich nicht an gezielte Rachebenotungen (obwohl es die im Einzelfall auch geben mag), sondern an ein subjektiv schlechteres Gefühl, das der Lehrer mit dem ihn kritisierenden Schüler verbindet und das sich bei der Wahl der Zeugnisnote, die ja immer ein Stück weit subjektiv ist, auswirken wird. Nicht immer und bei jedem Einzelfall, aber im Mittel.
Meine Güte, was sind das für Mimosen, die man nicht kritisieren darf, ohne dass sie emotional daran zerbrechen???
Von "Zerbrechen" hat niemand gesprochen. Du holst Dir halt eine Hypothek auf Dein Betriebsklima ins Haus. Wie schwer diese wiegt, hängt von den Rahmenbedingungen ab.

Ich bin nocht nicht mal sicher, dass das nicht auch auf Dich persönlich zutreffen würde. Das ist wie bei Werbung: Alle sagen, dass Fernsehwerbung ihre Kaufentscheidungen nicht beeinflussen würde, weil sie ja schlau genug sind, die Werbung als solche zu erkennen und ihre Kaufentscheidungen nur an sachlichen Kriterien ausrichten. Dennoch bestreitet niemand ernsthaft, dass Werbung insgesamt wirkt, also die Verkaufszahlen fördert. Damit aber ist klar, dass all die Leute, die glauben, Werbung wirke bei ihnen nicht, sich etwas vormachen, weil sie nämlich nicht bewusst (!) wahrnehmen, wie die Werbung bei ihnen wirkt.

Bei der unbewussten Wirkung negativer emotionaler Einflüsse durch Kritik ist es nicht anders.
Professioneller Umgang mit Kollegen ist Freelancern vorbehalten?
Sich hinzustellen und zu sagen, es ist mir egal, was die Kollegen über mich denken, solange sie mich nur fachlich fürchten, äh, respektieren, ist Freelancern vorbehalten. Alle anderen müssen schauen, dass sie auch auf menschlich-emotionaler Ebene gut mit ihren Kollegen auskommen.
Du hast zum Beispiel den Vorgang einer Blutspende, an dem sich alle Elemente registrieren: Die Blutspende-Probenröhrchen, die physische Blutspende selbst, der Spender, etc. Alle implementieren ein subsribe/unsubsribe-Interface
Alle was? Alle Elemente? Was sind "Elemente" in diesem Zusammenhang? Klassen? Objektinstanzen? Oder etwas ganz anderes?
Ja, das ist etwas abstrakt, aber so hast du halt unterschiedlichste Elemente mit unterschiedlichsten Eigenschaften, die unter einem "Sammler" hängen können.
Und der "Sammler" ist das Interface? Und wenn er gerufen wird, woher weiß er dann, für welche Art "Element" er gerufen wird, angesichts der Tatsache, dass Interfaces als solche meines Wissens keinen Code enthalten können, also auch keinen, mit dessen Hilfe sie den richtigen Elementtyp (Blutspende-Probenröhrchen, die physische Blutspende selbst, der Spender, etc.) identifizieren könnten? Soweit ich weiß, enthalten erst die Implementierungen des Interfaces Code, aber dazu muss das Interface ja wissen, welche davon es aufrufen soll.

Re: Umfrage zu euren Erfahrungen mit ATC

Beitrag von ralf.wenzel (Top Expert / 3935 / 200 / 281 ) »
DeathAndPain hat geschrieben:
Professioneller Umgang mit Kollegen ist Freelancern vorbehalten?
Sich hinzustellen und zu sagen, es ist mir egal, was die Kollegen über mich denken, solange sie mich nur fachlich fürchten, äh, respektieren, ist Freelancern vorbehalten.
Das habe ich so weder geschrieben noch gemeint. Du sprachst von "Liebe". Ich vermeide private Kontakte zu Kollegen.
DeathAndPain hat geschrieben:
Du hast zum Beispiel den Vorgang einer Blutspende, an dem sich alle Elemente registrieren: Die Blutspende-Probenröhrchen, die physische Blutspende selbst, der Spender, etc. Alle implementieren ein subsribe/unsubsribe-Interface
Alle was? Alle Elemente? Was sind "Elemente" in diesem Zusammenhang? Klassen? Objektinstanzen? Oder etwas ganz anderes?
Objektinstanzen.
DeathAndPain hat geschrieben:Und der "Sammler" ist das Interface? Und wenn er gerufen wird, woher weiß er dann, für welche Art "Element" er gerufen wird, angesichts der Tatsache, dass Interfaces als solche meines Wissens keinen Code enthalten können, also auch keinen, mit dessen Hilfe sie den richtigen Elementtyp (Blutspende-Probenröhrchen, die physische Blutspende selbst, der Spender, etc.) identifizieren könnten? Soweit ich weiß, enthalten erst die Implementierungen des Interfaces Code, aber dazu muss das Interface ja wissen, welche davon es aufrufen soll.
[/quote]

Der Sammler ist eine andere Objektinstanz, in der Hierarchie "höher", wenn du so willst. Du hast ein Objekt, das verschiedene Objekte in sich sammelt. Diese verschiedenen Objekte melden sich hierzu beim Sammler an (weil der Sammler ja nicht weiß, was für Objekte sich an ihn hängen, das macht das Ganze erweiterbar).

Das Interface selbst enthält keinen Code, aber die Interface-Implementierung in allen untergeordneten Elementen. Jedes Element hat für sich eine Logik, um den Schlüssel zu erzeugen, mit dem es sich am übergeordneten Sammler anmeldet.

Das Beispiel ist vielleicht einfacher zu verstehen, weil es weniger spezifisch ist


Ralf
Bild
Ralf Wenzel Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
PublikationenUngarische NotationXing

Re: Umfrage zu euren Erfahrungen mit ATC

Beitrag von ewx (Top Expert / 4849 / 313 / 642 ) »
DeathAndPain hat geschrieben:
ewx hat geschrieben:Ein quelltext, bei dem durch Anwenden des PP die Verständlichkeit „zerstört“ wird, ist definitiv nicht gut.
Wie sieht so ein Quelltext denn aus?
Das ist die Frage. Ich beobachte mal, wenn mir so ein Coding über den Weg läuft.
Die Aussage von mir ist aber auch in gewisser Weise quatsch. Ich meinte damit: Wenn jemand seinen Quelltext "extra" formatiert um ihn dadurch vermeintlich verständlicher zu machen, und dies durch Anwenden des PP verloren geht, dann ist es nicht optimal.
DeathAndPain hat geschrieben:
ewx hat geschrieben:Es ist also wichtig, zu erkennen, „wer in dem Kapitel ermordet wird“. Die Formatierung des quelltextes hilft dabei. Eine „extravagante“ Formatierung ist eher hinderlich.
Warum? "Extravagant" muss ja nicht "schlecht lesbar" bedeuten. Im Gegenteil kann es bedeuten, dass die Lesbarkeit trickreich heraufgesetzt worden ist.
Das ist richtig: MUSS nicht. Auch hier wäre ein Beispielcode vielleicht hilfreich. Die Chance, dass es die meisten als besser lesbar empfinden ist aber m. E. eher klein, weil durch die Standard-Formatierung des PP auch eine gewisse Gewöhnung bei ABAP-Programmierung vorhanden ist.

Re: Umfrage zu euren Erfahrungen mit ATC

Beitrag von ewx (Top Expert / 4849 / 313 / 642 ) »
DeathAndPain hat geschrieben: Interfaces sind so ziemlich das einzige OO-Element in ABAP, das ich nie so richtig begriffen habe.
Das ging und geht mir auch so. Wobei es sich bei mir sicherlich nicht um das einzige Element in OO handelt... ;)
Geholfen hat mir das hier:
Spiderman und Interfaces
Decorator-Pattern by Paul Hardy
Sicher nicht die einzige Verwendung, aber sehr hilfreich zum Verständnis einer Verwendung.

Vergleichbare Themen

30
Antw.
13199
Views
Umfrage
von ewx » 01.11.2012 16:55 • Verfasst in SAP - Allgemeines
1
Antw.
1125
Views
Umfrage zum Thema EWM
von rreichl » 23.10.2013 07:41 • Verfasst in Material Management & Produktionsplanung
22
Antw.
7444
Views
Umfrage: ABAP Objects / Webdynpro vs. classical Dynpro
von zeWa » 21.07.2014 13:35 • Verfasst in ABAP Objects®
20
Antw.
8943
Views
Erfahrungen mit Eclipse
von schick » 14.03.2018 09:51 • Verfasst in SAP - Allgemeines
3
Antw.
4802
Views
GUIXT Erfahrungen
von Murdock » 24.03.2014 11:38 • Verfasst in SAP - Allgemeines

Aktuelle Forenbeiträge

Daten an Tabelle binden
vor 13 Stunden von Bright4.5 3 / 1485
Regex in where
vor 14 Stunden von tar 6 / 158

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

Daten an Tabelle binden
vor 13 Stunden von Bright4.5 3 / 1485
Regex in where
vor 14 Stunden von tar 6 / 158

Unbeantwortete Forenbeiträge

aRFC im OO-Kontext
vor 5 Wochen von ralf.wenzel 1 / 3261
Hilfe bei SWEC/SWE2
September 2024 von retsch 1 / 9821