Klassennamen / Intefacenamen
Die Frage ist als "gelöst" markiert. Den entsprechend Beitrag findest du hier.
Beitrag
von ralf.wenzel (Top Expert / 3935 / 200 /
281
)
»
Moin,
man kann ja auch Klassen anlegen, die nicht auf *CL_ lauten bzw. Interfaces, die nicht mit *IF_ anfangen (*=Kundennamensraum). Macht ihr davon Gebrauch? Ich finde die Unterscheidung an sich schon etwas schräg (kenne ich auch so aus anderen Sprachen nicht) und wenn man einen ausreichend langen Namensraum-Namen hat, freut man ich über die drei Zeichen, die man damit gewinnt.
Wie macht ihr das?
Ralf
man kann ja auch Klassen anlegen, die nicht auf *CL_ lauten bzw. Interfaces, die nicht mit *IF_ anfangen (*=Kundennamensraum). Macht ihr davon Gebrauch? Ich finde die Unterscheidung an sich schon etwas schräg (kenne ich auch so aus anderen Sprachen nicht) und wenn man einen ausreichend langen Namensraum-Namen hat, freut man ich über die drei Zeichen, die man damit gewinnt.
Wie macht ihr das?
Ralf
Zuletzt geändert von ralf.wenzel am 26.03.2018 17:53, insgesamt 1-mal geändert.
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 black_adept (Top Expert / 4099 / 128 /
941
)
»
Ich finde den Namensraum lang genug und verwende die üblichen Startbuchstaben. Aber es gibt OpenSource Projekte die das anders handhaben
Gerade bei /xyz12/-Namensräumen ist es eigentlich Schwachsinn, weil ob da nun noch ein CL oder IF oder sonstwas steht, fällt kaum auf.
Aber ich mach's trotzdem
Gleiche Diskussion wie ungarische Notation.
Nur noch krasser. Weil's im Repository gleich jeder sieht.
Aber ich mach's trotzdem
Gleiche Diskussion wie ungarische Notation.
Nur noch krasser. Weil's im Repository gleich jeder sieht.
Beitrag
von ralf.wenzel (Top Expert / 3935 / 200 /
281
)
»
Warum unterscheiden die eigentlich zwischen IF und CL? Das hab ich noch nie verstanden.
Ralf
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Weil's ein eigener Klassentyp ist. Genau wie Ausnahmeklassen CX
Beitrag
von black_adept (Top Expert / 4099 / 128 /
941
)
»
Grob entspricht das dem Unterschied zwischen TYPE und DATAralf.wenzel hat geschrieben:Warum unterscheiden die eigentlich zwischen IF und CL? Das hab ich noch nie verstanden.
Beitrag
von ralf.wenzel (Top Expert / 3935 / 200 /
281
)
»
Und darum brauche ich ein Präfix IF_ oder CL_?
Was der Unterschied zwischen Interface und Klasse ist, weiß ich. Ich bezog meine Frage auf die Namensräume.
Ralf
Was der Unterschied zwischen Interface und Klasse ist, weiß ich. Ich bezog meine Frage auf die Namensräume.
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von black_adept (Top Expert / 4099 / 128 /
941
)
»
Interfaces und Klassen werden im aufrufenden Kontext in nahezu allen Belangen gleich behandelt. Da macht es Sinn sie in einen gemeinsamen Namensraum zu verfrachten wie geschehen. Um sie trotzdem einfach auseinander halten zu können bieten sich Prä- oder Suffixe an. Das ist nicht nur in ABAP so sondern ist gelebte Informatik.
Beitrag
von a-dead-trousers (Top Expert / 4399 / 223 /
1182
)
»
Ich nutze die Präfixe dahingehend, dass meine Klassen und Interfaces (bis auf die Präfixe) gleich heißen.
Überall dort man ein Objekt braucht wird nur das Interface verwendet und nicht die Klasse. So lassen sich ganz leicht einzelne Implementierungen (Klassen) austauschen ohne gleich die ganze Applikation umbauen zu müssen. Stichwort DAO.
Die Klassen die gleich lauten wie das Interface sind dann die "Default-Implementierungen".
Überall dort man ein Objekt braucht wird nur das Interface verwendet und nicht die Klasse. So lassen sich ganz leicht einzelne Implementierungen (Klassen) austauschen ohne gleich die ganze Applikation umbauen zu müssen. Stichwort DAO.
Die Klassen die gleich lauten wie das Interface sind dann die "Default-Implementierungen".
Folgende Benutzer bedankten sich beim Autor a-dead-trousers für den Beitrag:
gtoXX
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Beitrag
von ralf.wenzel (Top Expert / 3935 / 200 /
281
)
»
Du hast nur ein IF pro CL? Hm, bei mir läuft das anders - ich sitze gerade an einer Klasse, die hat ein Subscribe-Interface (das von vielen Klassen verwendet werden), eine Logging-Schnittstelle, eine Persistenz-Schnittstelle....
Oder hab ich dich falsch verstanden?
Ralf
Oder hab ich dich falsch verstanden?
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von a-dead-trousers (Top Expert / 4399 / 223 /
1182
)
»
Natürlich können Klassen auch mehrere Interfaces implementieren. Aber eine Klasse hat bei mir immer zumindest ein Interface in dem alle öffentlichen Schnittstellen definiert sind. Interfaces lassen sich dazu ja genauso wie die Klassen hierarchisch kombinieren. In allen Schnittstellen wo dann mit Objekten hantiert wird, wird auf die Interfaces referenziert und nicht auf die Klassen. Somit lässt sich die dahinterliegende Implementierung austauschen ohne das der Aufrufer das speziell berücksichtigen muss. Natürlich sollten dann die Methoden im Interface möglichst sprechend sein. Es nützt z.B. nicht eine Methode GET_BILL zu haben, wenn es je nach Implementierung einmal eine Kundenrechnung und ein anderes Mal eine Lieferantenrechnung ist. Dann müsste der Aufrufer das je nach Kontext unterscheiden und benötigt somit wieder das Wissen über die implementierenden Klassen.
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Beitrag
von black_adept (Top Expert / 4099 / 128 /
941
)
»
@adt: Warum Interfaces und nicht (abstrakte) Klassen ? In dem von dir angesprochenen DAO-Fall wäre der Unterschied wahrscheinlich marginal. Oder sogar die Standardklasse als nicht final definieren und die Mockklasse als erbende Klasse verwenden.
Davon abgesehen nervt mich bei Interfaces dass in der initialen Designphase Änderungen an der Schnittstelle das Anfassen aller Implementierungen erfordert was beim Klassenansatz wegfällt.
@Ralf: Ich versuche Klassen mit allzu vielen Interfaces zu vermeiden. Wenn es bei mir dazu kommt vermute ich meist einen Designfehler meinerseits weil die Klasse dann versucht zu viel zu tun. Ich sage mir dann immer dass das wie bei einem zu langen Programmmonolith ist und dass da Modularisierung angebracht ist.
Davon abgesehen nervt mich bei Interfaces dass in der initialen Designphase Änderungen an der Schnittstelle das Anfassen aller Implementierungen erfordert was beim Klassenansatz wegfällt.
@Ralf: Ich versuche Klassen mit allzu vielen Interfaces zu vermeiden. Wenn es bei mir dazu kommt vermute ich meist einen Designfehler meinerseits weil die Klasse dann versucht zu viel zu tun. Ich sage mir dann immer dass das wie bei einem zu langen Programmmonolith ist und dass da Modularisierung angebracht ist.
Beitrag
von ralf.wenzel (Top Expert / 3935 / 200 /
281
)
»
Auf die erste Frage kann ich antworten: Eine abstrakte Klasse kann ich nur einmal implementieren und bin auf den Vererbungszweig festgenagelt.
Wir haben hier lauter völlig unterschiedliche Klassen, die nichts miteinander zu tun haben - außer dass sie sich an einem Geschäftsprozess registrieren. Jedes Interface hat seinen Sinn, ist eine "Sicht" auf die Klasse. Das kann ich nicht modularisieren, das Business Object ist ja das richtige.
Ralf
Wir haben hier lauter völlig unterschiedliche Klassen, die nichts miteinander zu tun haben - außer dass sie sich an einem Geschäftsprozess registrieren. Jedes Interface hat seinen Sinn, ist eine "Sicht" auf die Klasse. Das kann ich nicht modularisieren, das Business Object ist ja das richtige.
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von a-dead-trousers (Top Expert / 4399 / 223 /
1182
)
»
Wegen der Mehrfachvererbung (oder so ähnlich) die ich bei reiner Klassenvererbung nicht habe.black_adept hat geschrieben:@adt: Warum Interfaces und nicht (abstrakte) Klassen ? In dem von dir angesprochenen DAO-Fall wäre der Unterschied wahrscheinlich marginal. Oder sogar die Standardklasse als nicht final definieren und die Mockklasse als erbende Klasse verwenden.
Beim Umbenennen von Interface-Komponenten unterstützt einen die SE80 schon recht gut dabei die einzelnen Implementierungen mitanzupassen. Zumindest werden sie "invalidiert". Wenn man das hingegen bei einer vererbten Methode einer Klasse macht...black_adept hat geschrieben:Davon abgesehen nervt mich bei Interfaces dass in der initialen Designphase Änderungen an der Schnittstelle das Anfassen aller Implementierungen erfordert was beim Klassenansatz wegfällt.
Daher verwende ich schon seit geraumer Zeit Eclipse für derartige Änderungen.
Außerdem ist es beim Ändern der Schnittstelle einer Klassen sehr mühselig die Aufrufstellen abzuklappern und anzupassen. Wenn es dann noch unterschiedliche Subklassen gibt, kann es passieren, dass man auch noch für diese die Aufrufstellen suchen muss. Bei einem gemeinsamen Interface muss man das nur einmal suchen.
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Also ich lege ja meistens eine abstrakte Klasse pro Interface an. Die abstrakte Klasse kann ja dann das Interface auch wieder abstrakt definieren, sodass die konkrete Implementierung des Interface auch wieder in der konkreten Klasse erfolgt. Das funktioniert natürlich auch für mehrere Interfaces. So habe ich eigentlich immer eine hohe Fexibilität und zusätzlich den Vorteil das ich gemeinsam genutztes Coding wunderbar in die abstrakte Klasse packen kann. Solltet ihr mal ausprobieren.
Die Präfixe erachte ich persönlich auch für überflüssig, zumal in der OO-Theorie es ja völlig egal sein sollte ob man jetzt ein Interface oder eine Klasse aufruft. Das von adt beschriebene Modell habe ich aber auch schon öfters gesehen.
Viele Grüße, Tapio
Die Präfixe erachte ich persönlich auch für überflüssig, zumal in der OO-Theorie es ja völlig egal sein sollte ob man jetzt ein Interface oder eine Klasse aufruft. Das von adt beschriebene Modell habe ich aber auch schon öfters gesehen.
Viele Grüße, Tapio
...entwickelnder Berater...beratender Entwickler
Vergleichbare Themen
Frage die ABAP Experten
Über diesen Beitrag
Die Frage ist als "gelöst" markiert. Den entsprechend Beitrag findest du hier.
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.