Java Ist eine Methode = Funktion in Java ?
- Ersteller vram78
- Erstellt am
M
mambokurt
Gast
Zespire schrieb:
Würde ich so nicht sehen, im Interface hast du ja eigentlich nur die Methodendefinitionen.
Wenn du unbedingt Funktionen suchst: eine Funktion ist eine Unterstruktur im Programm, die ein Ergebnis zurückgibt. Im Unterschied dazu gibts die Prozedur, die gibt ihr Ergebnis nur indirekt zurück. Hast du also eine Methode bei der am Ende irgendwo ein return x steht ist das eine Funktion. Ende Gelände.
mambokurt schrieb:
C ist zuallerst einmal imperativ, siehe z.B. Wikipedia. Du scheinst den Unterschied zwischen imperativ und prozedural nicht zu kennen.
mambokurt schrieb:
Das ist die Definition von imperativer Programmierung. Java ist in der Tat objektorientiert. Allerdings lässt sich innerhalb einer Klasse ja beliebig anonym schachteln, insofern könnte man darüber streiten, ob Java nicht eventuell doch auch prozedural ist. Prozedurale Programmierung bedeutet nämlich genau, dass man im Programm Funktionalität in verschiedene Fragmente aufteilt, die über beliebig aufgerufen/wiederverwendet werden können.
Streng genommen ist ja auch das ganze Klassen/Methoden-Konzept ein prozeduraler Ansatz, sofern man von expliziten Rückgabewerten und der hohen Abstraktionsebene absieht.
mambokurt schrieb:
Nein, Klassen sind immer direkt über die Klasse aufrufbar. Sonst könnte man z.B. in Java auch die Main gar nicht callen. Um Funktionalität an Klassen zu binden, ist in Java das keyword static reserviert.
Das funktioniert in allen großen Sprachen (C++, Java, Python, ...) ohne ein Objekt instanziert zu haben - wäre auch unsinnig, wenn nicht.
mambokurt schrieb:
Zum Einen sind es bei OOP eben keine Funktionen, sondern Methoden. Zum Anderen sind die globalen Variablen keine Attribute.
Attribute sind in Java Exemplarvariablen (engl.: instance variables) oder Felder (engl.: fields). Felder können konstant oder variabel (keyword final in Java) sein.
Globale Variablen gibt es in Java gar nicht, da Java konsequent objektorientiert ist. Klassen können allerdings Klassenfelder bzw. -variablen haben. Das sind jene Attribute, die mit static deklariert wurden. Diese sind ausschließlich über die Klasse zu callen und können von allen Objekten einer Klasse abgerufen werden.
mambokurt schrieb:
Nein, das hat gar nichts miteinander zu tun.
Java kennt nur Einfachvererbung - im Unterschied zu etwa Python oder C++, die Mehrfachvererbung bieten. Das ist der Hauptgrund, warum es in Java Interfaces gibt.
Ein Interface ist eine Schnittstelle, die einen "groben Bauplan" vorgibt. Implementiert eine Klasse ein Interface, setzt also die Vorgaben der Schnittstelle konkret um, so setzt sie damit den Typen des Interfaces um.
So könnte man z.B. eine Klasse Auto haben, sowie eine Sub-Klasse Audi, die von Auto erbt. Ebenso könnte man eine Klasse Autozeitschrift haben. Auto und Autozeitschrift haben dann natürlich nichts gemein, außer auf abstrakter Ebene: beide können ein Verkaufsobjekt (mit Preis, Verkaufsfunktion, ...) sein. Deshalb könnten beide ein Interface "Buyable" implementieren.
Diese Polymorphie ist der Grund für Interfaces in Java. Es können beliebig viele Interfaces implementiert werden.
Unabhängig davon ist es ein nettes Gimmick, um sich auf abstrakte Art und Weise auf Funktionalität zu einigen. Entwickler 1 hat als Ersteller von "Auto" nichts mit Entwickler 2 am Hut, der "Autozeitschrift" entwickelt. Beide müssen aber irgendwie die Verkaufsfunktionalität umsetzen. Damit dies innerhalb eines Projektes standardisiert von Statten geht, einigt man sich vorab auf ein gemeinsames Interface.
Mit der Kommunikation von Objekten untereinander hat das wenig zu tun, sondern vielmehr mit der Typisierung und der (Einfach)Vererbung.
Das sieht man z.B. auch daran, dass der instanceof Operator für implementierte Interfaces zu true evaluiert. "Autozeitschrift instanceof Buyable" würde z.B. true zurückgeben.
Um eine Kommunikation von Objekten untereinander zu realisierien gibt es beispielsweise das Observer-Pattern.
mambokurt schrieb:
Methodendeklaration.
mambokurt schrieb:
Nicht zwangsläufig. Viele Sprachen haben diese Terminologie ja aufgeweicht. In C z.B. spricht man immer von Funktionen. Eine Prozedur in C ist schlicht eine Funktion mit dem Rückgabetyp void.
In Java hingegen spricht man immer von Methoden, unabhängig davon ob dort return oder nicht steht, ist das in Java nie eine Prozedur oder Funktion. Eine Prozedur ist in Java auch einfach nur eine Methode mit Rückgabetyp void.
Wenn man in Java unbedingt eine Funktion möchte, dann kann man z.B. eine Lambda-Function nutzen. Das ist zwar eine anonyme Funktion, aber auch in Java eine wirkliche Funktion:
Code:
MathOperation addition = (int a, int b) -> a + b;Diese Lambda-Function ist z.B. eine MathOperation, die eine simple Addition definiert und eben die Summe zweier Integer zurückgibt.
Der Unterschied zwischen Funktion und Prozedur ist der Rückgabetyp (und in manchen Sprachen wurde das eben aufgeweicht), nicht aber der Unterschied zwischen Funktion und Methode.
Wie der Stackoverflow-Link hier längst aufgeklärt hat: der Unterschied zwischen Funktion und Methode ist die Bindung an ein Objekt oder eine Klasse (im Falle einer Klassenmethode (static)).
Der praktische Unterschied (Methode <-> Funktion) entsteht also dadurch, dass bei OOP einer Methode immer implizit das übergeordnete Objekt (oder eben die Klasse) mit an die Methode übergeben wird. Quasi als "versteckter", zusätzlicher Parameter.
In Python z.B. ist wegen dem Zen of Python (ein Auszug: "Explicit is better than implicit") diese Übergabe explizit:
Code:
def some_method(self, some_parameter):
# do something...Dort wird durch das keyword "self" nämlich genau das Objekt selbst explizit übergeben.
Damit hat man indirekt im Übrigen auch schon den einzig weiteren Unterschied zwischen Funktionen und Methoden geklärt: durch die Übergabe des Objektes, indem die Methode deklariert wurde, hat die Methode Zugriff auf den kompletten Scope des Objekts, kann also z.B. auf die Attribute zugreifen.
mambokurt schrieb:
...oder auch nicht
Zuletzt bearbeitet:
ascer schrieb:
Vielleicht solltest du den Thread nochmal verfolgen. Er wollte exemplarisch darauf hinaus, dass C im Gegensatz zu Java prozedural ist. Imperativ sind beide Sprachen, denn imperativ und objektorientiert sind nicht orthogonal zueinander (im Gegensatz zu imperativ und deklarativ).
ascer schrieb:
Klar hat es das, und wenn du das anders verstehst, dann willst du es wohl missverstehen. Deine Ausführungen zum Existenzgrund von Interfaces sind korrekt und schön und gut, widersprechen aber nirgends seiner Aussage (im Gegenteil). Jeder einzelne Methodenaufruf zwischen Objekten ist Kommunikation, und diese über Abstraktion (wie beispielsweise ein Interface) lose zu koppeln ist je nach Kontext sogar angebracht.
ascer schrieb:
Na, da haben wir es doch. Wobei "nettes Gimmick" wohl die Untertreibung schlechthin ist. DAS ist das Hauptfeature von Interfaces. Die fehlende Mehrfachvererbung ist natürlich der Grund, warum man so ein Konstrukt wie Interfaces überhaupt erst einführen musste, aber das ist ein technisches Detail. Die Java-Schöpfer hätten sich genau so gut darauf einigen können, das man Mehrfachvererbung im eigentlichen Sinne zwar weglässt, für abstrakte Klassen mit ausschließlich abstrakten Membern aber erlaubt. Wäre wohl zu verwirrend gewesen, hätte aber den selben Effekt gehabt, ganz ohne Interfaces.
ascer schrieb:
Wäre ja auch schlimm wenn nicht
ascer schrieb:
Wie gesagt, jeder Methodenaufruf ist Kommunikation. Da willst du hoffentlich nicht überall das Observer Pattern implementieren. Und sowieso: das Observer Pattern ist gerade ein Parabebeispiel für den Einsatz von Interfaces (Observable und Co.).
ascer schrieb:
Es ist im Endeffekt auch nur syntaktischer Zucker für einen Methodenaufruf (idR. ein statischer Methodenaufruf auf der Klasse, in der der Entwickler das Lambda verwendet. Die Methode wird generiert). Aus Sicht des Entwicklers kommt es einer Funktion im eigentlichen Sinne aber sehr Nahe, das stimmt.
ascer schrieb:...oder auch nicht
mambokurt mag sich hier und da ungenau ausgedrückt haben, aber dein Beitrag wirkt doch arg übermotiviert.
Zuletzt bearbeitet:
fz21z
Lt. Junior Grade
- Registriert
- Apr. 2009
- Beiträge
- 300
vram78 schrieb:Ich verstehe garnix mehr
Ja, verrückter Thread, bisschen 'überverkomplizierungen'.
Der Stackoverflow Link ist vollkommen in Ordnung, und die Beiträge dazu haben nicht umsonst so viele Upvotes. Der als korrekt markierte Beitrag hat übrigens nur ein paar Sätze
M
mambokurt
Gast
ascer schrieb:
"Prozedurale Programmierung ist ein Programmierparadigma, nach dem Computerprogramme entwickelt werden können. Die Bezeichnung ist nicht eindeutig; in der Literatur wird sie für verschiedene Bedeutungen verwendet:
-als Erweiterung des imperativen Paradigmas um den Ansatz, Algorithmen in überschaubare Teile zu zerlegen, die anhand einer definierten Schnittstelle aufrufbar sind.[1]
-innerhalb des imperativen Paradigmas als Gegenstück zur objektorientierten Programmierung[2]"
Vielleicht noch Wiki zur imperativen Programmierung:
"Abweichende Bezeichnungen: In der Literatur wird dieses Entwicklungskonzept zum Teil auch „imperativ/prozedural“, „algorithmisch“[2] oder auch „zustandsorientiert“[3] genannt. Auch die Bezeichnung „prozedurale Programmierung“ (siehe dort) wird zum Teil synonym verwendet, was jedoch abweichend auch mit „Verwendung von Prozeduren“ definiert wird."
ascer schrieb:
Dass du Methoden von Klassen static machen kannst und direkt aufrufen ist mir vollkommen klar, das dürfte aber eher nicht die 'normale' Vorgehensweise in der Objektorientierung sein, oder hast du 50 Klassen rumfliegen, die du direkt aufrufst statt Objekte zu instantiieren?
ascer schrieb:
Für mich sind Instanzvariablen globale Variablen, weil sie nicht nur innerhalb der einzelnen Methoden existieren sonden global im Objekt. Blöd ausgedrückt, ja. Sowas wie eine echte globale Variable habe ich Leben noch nicht benutzt, und ich vermeide das auch eher proaktiv
ascer schrieb:
s.o.
ascer schrieb:
Merkste selber, oder? Polymorphie -> geschenkt. Es ging eher darum dass der TE der Meinung war übers Interface definiert seien es Funktionen statt Methoden.
Wenn mein Objext X von Objekt Y gerne Daten hätte, bekommt es die entweder direkt indem es eine Funktion von Y aufruft oder Y implementiert halt ein Interface und X muss sich daran halten(was letztlich die selbe Soße ist).
Listener/Observer ist eine Art zu definieren, wann zwei Objekte Daten austauschen, aber wie sie das letztendlich machen -> s.O.
Haste recht, das hat jetzt bestimmt keiner verstanden.
Ich sag doch: da gibts zig Definitionen, am Besten für jede Sprache eine eigene leicht abgewandelte. Wenn man sich an die Definition hält dass Funktionen Werte zurückgeben und Prozeduren nicht, kann man wenigstens halbwegs einheitlich bleiben (und Void wäre dann eben _kein_ Wert der zurückgegeben wird). Nach der Definition sind Methoden dann eben je nach Rückgabetyp auch Funktionen oder Prozeduren. Man kann sich daran aufhängen und Haare spalten, oder man akzeptiert einfach dass es zig Definitionen gibt und das eine davon sein könnte.
Habe ich anders auch nie gesagt. Eine Methode ist eine Methode und gleichzeitig eine Funktion oder Prozedur, wenn man nach der Definition mit dem Rückgabetypen geht.
Ähnliche Themen
![[ChAoZ]](https://pics.computerbase.de/forum/avatars/s/491/491529.jpg?1618073566){kind=avatar}
