Unterschied zwichen einer Methode und einer Funktion

[*john 0]

Im Sprachgebrauch der objektorientierten Programmierung sind Methoden nicht nur bloß Funktionen in Klassen, sondern sie sind polymorph. D.h. ruft man über das implizite oder explizite (das hängt von der Programmiersprache ab) Interface die Methode auf, wird die konkrete Methode abhängig von der Klasse des Objektes ausgewählt. Wie das konkret funktioniert hängt von der verwendeten Programmiersprache ab. Eine Funktion wird hingegen immer nur mit den statischen Typinformationen verwendet, die beim übersetzen vorhanden waren.

[Bashar]

Ursprünglich ist eine Methode in der OOP eine die Implementierung des konkreten Verhaltens, mit dem ein Objekt auf eine Nachricht reagiert. Also z.B. der Code, mit dem ein Button auf die Nachricht Draw reagiert, und der völlig anders von der Methode für diese Nachricht in einem Textfeld ist, während ein String diese Nachricht gar nicht versteht und entsprechend keine Methode dafür besitzt. In den üblichen Mainstream-OOP-Sprachen hat man dieses Konzept mehr oder weniger durch Funktionen implementiert, die zu einer Klasse gehören. Wenn man korrekt sein möchte, ist also die Deklaration einer abstrakten Memberfunktion mit der Deklaration einer Nachricht und jede Implementation davon davon mit der Definition einer Methode gleichzusetzen.

Außerhalb theoretischer Texte und Objektsystemen wie dem von Smalltalk oder CLOS wird diese Unterscheidung aber meiner Erfahrung nach verwischt.

[5cript]

@john-0
Kannst du das untermauern, weil das wäre mir neu.

[*john 0]

@5cript sagte in Unterschied zwichen einer Methode und einer Funktion:

@john-0
Kannst du das untermauern, weil das wäre mir neu.

Der wesentliche Schritt von prozeduraler Programmierung hin zur objektorientierten Programmierung, war die Einführung des Dispatchings, d.h. die Auswahl einer Methode in Abhängigkeit des Objekttyps eines oder mehrerer Parameters der Methode. In den meisten OO-Sprachen wird eine Syntax ähnlich object.method() verwendet, d.h. das Objekt wird als impliziter Parameter an die Methode übergeben, den man mit this, self o.ä. referenzieren kann. Aber auch das trifft nicht auf alle OO-Sprachen zu. Es gibt da einige, da muss man freistehende Methode schreiben, und das Objekt als Parameter explizit übergeben, das ist in Hinsicht auf Mutiple Dispatch auch der sinnvoller Weg, und der SmallTalk Sprachgebrauch man schicke an ein Objekt eine Nachricht ist dann ganz widersinnig. Denn an welches Objekt verschickt man die Nachricht, wenn es mehr als eines gibt?

Es gibt seit Jahrzehnten einen Streit darüber was „richtiges“ OOP sei, und das entzündet sich konkret an der Art des Dispatchings also an der Art und Weise wie die Laufzeitumgebung die konkrete Methode auswählt. Das hängt indirekt mit der deutlich älteren Diskussion zusammen, ob man strenge oder schwacher Typisierung den Vorzug geben sollte. Bei der einen Varianten werden explizite Interfaces bzw. Ableitungen in der Klassenhierachie notwendig, bei der anderen wird auf gut Glück einfach zur Laufzeit nachgesehen, ob es eine Methode mit dem passenden Namen und den passenden benannten Parametern gibt.

Nichtsdestoweniger wird auch bei der letzten Variante gegen ein Interface entwickelt, da ist es bloß implizit. Bei C++ wurde ursprünglich der Weg der strengen Typisierung gegangen, mit den Templates weicht man dass nun wieder auf. Die Concepts sind dafür ein Paradigma. Anstatt abstrakte Interfaces einzufordern, werden einzelne Eigenschaften abgefragt.

Im Gegensatz dazu werden bei einfachen Funktionen, Prozeduren, Subroutines, … die Parameter zum Übersetzungszeitpunkt statisch kodiert. Bestenfalls kann man noch Zeiger übergeben, und dann diese später casten. Wobei dies in vielen Sprachen gar nicht möglich ist. Falls Dir Fortran COMMON Blöcke etwas sagen, das ist der übelste Weg, wie man Parameter an eine Funktion übergibt.

[Th69]

s.a. Multimethode

[5cript]

Das ist ja alles schön und gut, aber mir ging es mehr darum, dass allgemein "Methode" nicht die polymorphie voraussetzt, und das klang so.

Prozedur:
void something()

Funktion
int something()

Methode
T something(U* this, ...)

Letztlich bin ich auch nicht so der Typ, der Wörtern übermäßig viel Wichtigkeit beimisst.
Wenn es jetzt jemand Unterroutine mit verstecktem this Parameter nennt ist mir das auch wurscht.

[*john 0]

@5cript sagte in Unterschied zwichen einer Methode und einer Funktion:

Das ist ja alles schön und gut, aber mir ging es mehr darum, dass allgemein "Methode" nicht die polymorphie voraussetzt, und das klang so.

Ohne die Fähigkeit zur Polymorphie ist OO witzlos, d.h. eine Methode zeichnet sich gerade dadurch aus, dass es dieses Potential gibt.

[Swordfish]

@john-0 Witzlos ist, daß Du einerseits genau weißt, daß sich die Welt glaubenskriegartig darüber uneins ist, was "richtige" OOP ist und andererseits stockstarrsteif Deine eigene Meinung als die "Wahrheit" darstellst.

[hustbaer]

@5cript sagte in Unterschied zwichen einer Methode und einer Funktion:

Wenn es jetzt jemand Unterroutine mit verstecktem this Parameter nennt ist mir das auch wurscht.

In Java werden auch statische "member functions" als "method" bezeichnet - "static method" halt in dem Fall. Der einzige Unterschied zu einer "free function" ist dann dass die Dinger Zugriff auf protected/private Zeugs der Klasse haben.

[*john 0]

@Swordfish sagte in Unterschied zwichen einer Methode und einer Funktion:

@john-0 Witzlos ist, daß Du einerseits genau weißt, daß sich die Welt glaubenskriegartig darüber uneins ist, was "richtige" OOP ist und andererseits stockstarrsteif Deine eigene Meinung als die "Wahrheit" darstellst.

Wie wäre es mit einer Quellenangabe zum Thema OOP ohne Polymorphismus? Darauf bin ich wirklich gespannt.