Unterschied zwichen einer Methode und einer Funktion

[LotosKaiser04]

Wie oben beschrieben ist das meine Frage.
Ich habe es irgendwie verstanden das Methoden Funktiononen sind aber halt nur in einer Klasse.
Hab ich das so richtig verstanden oder kann mich einer eines besseren belleren?
LG Alexander

[5cript]

ja

[Swordfish]

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

Ich habe es irgendwie verstanden das Methoden Funktiononen sind aber halt nur in einer Klasse.

Darauf bezieht sich @5cript s "ja". Technisch gesehen sind Methoden genau dasselbe wie (freie) Funktionen mit dem unterschied, daß bei nicht-statischen Memberfunktionen ("Methoden") this, also die Adresse des Objekts für das die Funktion aufgerufen wird, als erster nicht sichtbarer Parameter übergeben wird.

[hustbaer]

@LotosKaiser04
Methode, Funktion, Prozedur, Unterprogramm (sowie einige mehr) - das sind letztlich alles nur Wörter für das selbe grundlegende Konzept.

Siehe z.B. https://en.wikipedia.org/wiki/Subroutine

Die genaue Bedeutung des Begriffs Funktion ist kontextabhängig. Wenn man von Funktion vs. Methode spricht, dann ist mit Funktion etwas gemeint was nicht zu einer Klasse gehört. Wenn allerdings nur der Begriff Funktion verwendet wird, dann ist das nicht klar. In C++ werden alle Unterprogramme als Funktionen bezeichnet, auch welche die zu einer Klasse gehören. Wenn die Unterscheidung wichtig ist, dann verwendet man "free function" vs. "member function". Einfach nur "function" kann dann beides sein, bzw. wird dann verwendet wenn die Unterscheidung nicht wichtig ist.

Umgekehrt ist beim Begriff Methode aber ziemlich* klar dass diese zu einer Klasse gehört.

*: Manche Programmierer mit starkem Java-Fokus sprechen immer von Methoden, auch wenn sie über Programme in anderen Sprachen sprechen. Weil sie das so gewohnt sind. In Java gibt es ja auch nichts anderes. Ist mir schon öfters passiert dass jemand gesagt hat "machen wir halt eine neue Methode", wenn er eigentlich eine freie Funktion meinte. Ist aber eigentlich falsch.

[*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.