Redefinierte Methode - Attribute

Re: Redefinierte Methode - Attribute

black_adept hat geschrieben:Hmm - ich finde das eigentlich gar nicht so schön. Es erfüllt sicherlich den Zweck, aber auch wenn SAP das selber verwendet zeigt das nur, dass sie selber das Overloading vermissen bzw. sich nur so zu behelfen wissen.
Aber gerade die Idee, dass man Pflichtparameter im Interface definiert um dann weitere Parameter via implementierender Klasse zur Verfügung zu haben stößt mir schon recht bitter auf. Dann kann doch gleich alle Methoden genau so definieren und sich die ganzen Schnittstellen von Methoden ganz sparen.

Da bin ich ganz deiner Meinung, aber ...

a-dead-trousers hat geschrieben:Wenn man in dieses Methoden-Schnittstelle-Interface-Konzept etwas Zeit investiert sollte man auch gänzlich ohne das CASTING auf die implementierende Klasse auskommen können.

Sieh die Schnittstelle einfach als eigenes Objekt an. Gleich wie bei "normalen" Klassen steht und fällt das Konzept damit wie es designed ist.

Re: Redefinierte Methode - Attribute

black_adept hat geschrieben:"Normale" Schnittstellen haben importing, exporting, changing Parameter: Diese werden durch die Signatur unterschieden. Wie unterscheidet SAP das denn in den Interfacemethoden? Namenskonvention oder die Anwesenheit von Set- und/oder Getmethoden für die Attribute?

Hauptsächlich Set- und Getmethoden.

black_adept hat geschrieben:Unterscheidung "byValue"/"byReference" kann ich mir vorstellen - das Arbeiten damit scheint mir hingegen unhandlich zu werden. ( Und fast zwingend den Einsatz von Settern und Gettern zu erfordern, wenn man einen einheitlichen Zugriff wünscht )

Ich selbst verwende für viele Sachen lieber Public Read-Only Attribute anstatt Getter, da ich diese z.B. direkt in SQL-Selects verwenden kann ohne zuerst ein lokales Datenfeld anlegen zu müssen. Setter sind jedoch meines Erachtens immer Pflicht z.B. für das Sanitizing.

black_adept hat geschrieben:Von mir gern verwendete Returningparameter scheinen ja implizit ausgeschlossen zu sein, da diese Methoden nur dieses Interface als Parameter haben, wodurch dann ja zusätzlicher Returning-Parameter entfällt.

Der Returning-Parameter kann ja auch wieder ein Interface sein. z.b. wenn die Funktionalität der Methode dazu dient ein neues Objekt zu erzeugen.
Oder es geht auch Changing wenn ein Objekt "transformiert" werden soll.

black_adept hat geschrieben:Somit entfällt auch die Frage nach "Preferred" Parametern.

Wenn du damit meinst, dass man nur schwer sicherstellen kann ob alle benötigten Parameter versorgt sind, kann man ja auch eine Prüfmethode hinzufügen die eine Exception im Fehlerfall wirft. Gut, es ist etwas aufwändiger als auf die Syntax-Prüfung zu vertrauen und schlägt auch erst zur Laufzeit an, aber wie es überall so ist, kann man nicht nur Vorteile haben.

black_adept hat geschrieben:Aber "optionale" Parameter müssten ja auch irgendwie kenntlich gemacht werden. Auch hier die Frage: Wie?

Gute Frage! Nächste!
Nein, ernsthaft: Darüber hab ich mir noch keine Gedanken gemacht. Vielleicht könnte man ein zusätzliches Attribut versorgen das bei Aufruf der Setmethode zum Parameter gesetzt wird. Aber siehe dazu auch deine nächste Frage.

black_adept hat geschrieben:Wie wird denn bei dieser Methodik der Prädikatoperator "is supplied" abgebildet?

Obwohl ich das selbst sehr gern verwende, habe ich mir sagen lassen das, dass eigentlich ein no-go ist. Die Programmlogik sollte nicht vom vorhandensein von Parametern beeinflusst werden können. Bestes Beispiel: Eine solche Methode lässt sich z.B. über die "Testen"-Funktion in der se80 nicht in allen Kombinationen ausführen.

black_adept hat geschrieben:Und noch mal ein Kommentar zur Originalfrage dieses Thread an tseng:
Warum willst du überhaupt die Signatur der Methode ändern?
Diejenigen Aufrufer einer erweiterten Methode müssten ja vorher sicherstellen, dass sie es mit der abgeleiteten Klasse zu tun haben und nicht mit der Oberklasse um die Schnittstelle korrekt zu befüllen.
Aber wenn ich weiß, dass ich die Unterklasse zur Verfügung habe, kann ich auch alternativ vorgehen, indem ich der abgeleiteten Klasse eine neue Methode verpasse, welche dann von dem Aufrufer zusätzlich/alternativ zur Originalmethode aufgerufen wird.

Da muss ich jetzt auch noch was dazu sagen, auch wenn die Fragen nicht direkt an mich gerichtet waren:
Ich nehme an er bezieht sich auf andere Programmiersprachen wie z.B. Java. Dort kann man jederzeit eine neue Methode einführen die denselben Namen hat wie eine andere der Oberklasse aber deren Parameter unterschiedlich sind. Ich finde, eine sehr elegante Lösung um sich neue Methodennamen nicht aus den Fingern saugen zu müssen. Was ich in SAP schon oft machen musste, vor allem bei nur 30 möglichen Zeichen.
ABER: Wie ich Eingangs schon erwähnt habe, handelt es sich bei solchen Methoden NICHT um Redefinitionen. Da in Java die Signatur einer Methode zu deren Definition gehört, handelt es sich in Wirklichkeit um eine von der Hauptklasse völlig losgelöste, neue Methode.

Warum er das trotzdem gerne hätte: Ganz einfach, er möchte Methode X einer Klasse überladen um zusätzliche Änderungen damit durchzuführen, aber trotzdem die Originalmethode auch noch aufrufen können, ohne jetzt einen neuen Methodennamen zu "verbrauchen". Erinnert ein bischen an das erwähnte Vorgehen unter Java.

lg ADT

Re: Redefinierte Methode - Attribute

black_adept hat geschrieben:[...] aber gerade wenn ich einen Exporting-Parameter nicht benötige kann ich sehr oft auf zeitfressende Operationen verzichten, so dass ich dieser Aussage aufs Heftigste widersprechen möchte.

Aufs Allerheftigste (aus genanntem Grund)!

Re: Redefinierte Methode - Attribute

black_adept hat geschrieben:

a-dead-trousers hat geschrieben: Oder als (einzigen) Parameter in der Methoden-Schnittstelle ein Interface (als Parametertyp) verwenden. Dieses Interface definiert alle notwendigen "Parameter" für die korrekte Verarbeitung der Methode als Attribute oder über SET-/GET-Methoden.

Hmm - ich finde das eigentlich gar nicht so schön. Es erfüllt sicherlich den Zweck, aber auch wenn SAP das selber verwendet zeigt das nur, dass sie selber das Overloading vermissen bzw. sich nur so zu behelfen wissen.
Aber gerade die Idee, dass man Pflichtparameter im Interface definiert um dann weitere Parameter via implementierender Klasse zur Verfügung zu haben stößt mir schon recht bitter auf. Dann kann doch gleich alle Methoden genau so definieren und sich die ganzen Schnittstellen von Methoden ganz sparen.
Zumal man hier in meinen Augen deutlich schönere Alternativen hätte:
Pflichtfelder braucht man eigentlich nicht über diese Krücke zu übergeben, da diese direkt in die Signatur der Methode eingehen sollten. Wenn man dann tatsächlich noch overloading unterstützen will kann man das ja von mir aus mit der o.a. oder einer alternativen Technik machen ( DataRef auf Struktur wäre wohl ähnlich geeignet ) - aber eben nur für den Nicht-Pflichtteil der Methode .

Für den Nicht-Pflichtteil einer Methode machen das andere auch relativ einfach. Sie übergeben ein Objekt. Du findest oft die Kombination z.b. ParamArgs oder Metadata, gerade bei Events. Sicher wäre hin- und wieder ein Overloading wünschenswert. Gerade wenn man Framworks macht. Allerdings ist auch immer die Frage ob Overloading nicht Dinge komplizierter macht. Verwendbar ist es ja sowieso nur in der implementierenden Klasse.