Aus welche Methode wurde aufgerufen?
-
Fellhuhn schrieb:
Nö. Prozedure umschließt alles. Habe ich auch noch nie anders gehört
Dann schließe ich mich Simon an, diese Variante habe ich noch nie gehört. Die Unterscheidung die Du meinst kenne ich nur von Basic als Sub <-> Function und von Pascal als Procedure <-> Function.
-
Wenn man schon objektorientiert Programmiert, sollte man auch die eindeutigen Namenskonventionen kennen und auch verwenden.
Also unabhängig ob der C++ Standard dies so vorschreibt.
Sonst kommt man immer früher oder später an einen Punkt, wo man aneinander vorbeiredet.
-
Also unabhängig ob der C++ Standard dies so vorschreibt oder nicht.
-
Fellhuhn schrieb:
LordJaxom schrieb:
Fellhuhn schrieb:
Für mich ist eine Methode eine Funktion ohne Rückgabewert. Und eine Funktion eine Methode mit.
Ich glaube da verwechselst Du jetzt aber Methode mit Prozedur
Nö. Prozedure umschließt alles. Habe ich auch noch nie anders gehört. *shrug*
Also wenn ich auf die Fachliteratur zurück schließe die ich zu Hause habe [Schwerpunkt C++/UML/C#], ist der verbreitete Konsenz (Der sich doch recht stark herauskristallisiert; Ich schätze mal mit etwa 80+%):
Funktion vs. Methode: Der Begriff Funktion wird für die Freien, der Begriff Methoden für die an Klassen gebundenen Funktionen verwendet. Letzteres gilt auch wenn die Funktion statisch deklariert wird (dann namentlich statische Methode genannt).
Prozedur: (Sofern der Begriff überhaupt noch in aktueller Lektüre verwendet wird)
Eine Funktion ohne Rückgabewert.Aber um nochmal auf das Thema zurück zu kommen: Häufig (aber nicht immer) deutet es nach meiner Erfahrung auf einen Designfehler hin wenn das Verhalten einer Methode sich durch seinen Aufruf beeinflusst (Meist gibt es dann bessere Möglichkeiten über Überladung oder Polymorphie).
cu André
-
olli_fedder schrieb:
Wenn man schon objektorientiert Programmiert, sollte man auch die eindeutigen Namenskonventionen kennen und auch verwenden.
...Das ist ein hehres Ziel, halte ich aber für illusorisch.
Man kann einfach nicht sagen "is OO" und damit ist alles gleich - es bleiben einfach doch recht unterschiedliche (sprachspezifische) Konzepte/Denk- und Herangehensweisen. ... und diese resultieren einfach auch in unterschiedlichen Begriffen.
Da wird eine "Zwangsharmonisierung der Begriffe" eher mehr Verwirrung erzeugen als beseitigen. Als Beispiel nehme ich mal den Begriff "Referenz", der in Java und in C++ etwas sehr anderes meint - und das wirkt sich gerade NICHT positov aus.
Ein anderes Beispiel ist der Begriff "Schnittstelle", zu der in C++ auch "freie Funktionen" gehören können (deswegen auch spezielle Lookup-Regeln), während man in Java darunter schon eine bestimmte (sprachspezifische) Technik versteht.Gruß,
Simon2.
-
asc schrieb:
...
Aber um nochmal auf das Thema zurück zu kommen: Häufig (aber nicht immer) deutet es nach meiner Erfahrung auf einen Designfehler hin wenn das Verhalten einer Methode sich durch seinen Aufruf beeinflusst (Meist gibt es dann bessere Möglichkeiten über Überladung oder Polymorphie).cu André
Ein Arbeitskollege von mir drückt das aus als "'Do_This_Or_That'-Parameter sind immer schlecht !"
... und in meiner Erfahrung sich das immer bestätigt.
(Klar, manchmal waren alle Alternativen NOCH schlechter, aber das macht diese nicht "gut")Gruß,
Simon2.
-
Zur Unterschied ob "zur klassend gehörend" oder nicht, wird hier eigentlich immer "Member-" davorgesetzt.
int moep() ist eine Funktion
void moep() ist eine Methode
int Narf::moep() ist eine Member-Funktion
void Narf::moep() ist eine Member-Methode"Durchsetzen" tut das aber auch niemand. Da werden meist alle Begriffe durcheinander geworfen und trotzdem versteht jeder was gemeint ist.
-
Eine Methode ist in der OOP das, was ein Objekt ausführt, wenn es eine Nachricht empfängt. Die Frage kann jetzt nur noch sein, wie gut oder schlecht die programmiersprachlichen Elemente die OOP-Elemente abbilden. Also ob eine Memberfunktion jetzt Methode heißen darf oder nicht beispielsweise. Irgendeine Phantasienomenklatur (@Fellhuhn) ist mit Sicherheit nicht sinnvoll.
-
ups, 2. Seite übersehen.
Dann erläutere ich mal partiell das Problem:
Es geht um einen Chartparser. Das ist ein System um einen Satz mit einer syntaktischen (Struktur zu versehen). Diese wird in einer Chart gespeichert.
Da ein Satz aber nicht immer nur mit genau 1 Syntaxbaum geparst werden kann muss man die Ambiguitäten irgendwie verwalten.Naumann/Langer schlagen dafür die implizite Kantenrepräsentation vor. Siehe dazu S. Naumann & H. Langer: Parsing. Eine Einführung in die maschinelle Analyse natürlicher Sprache. Teubner, Stuttgart 1994, S. 161, Kapitel 7.4.2.
Wens wirklich interessiert: Hier gibts das Buch: http://www.uni-trier.de/index.php?id=13891
[Kauderwelsch]
Und in Prolog hab ich das damals so gemacht, dass ich mir gemerkt habe, in welchem Kontext eine Kante in die Chart eingetragen wurde um die implizite Kanten-Repräsentation umzusetzen.
[/Kauderwelsch]
-
Fellhuhn schrieb:
...
int moep() ist eine Funktion
void moep() ist eine Methode
int Narf::moep() ist eine Member-Funktion
void Narf::moep() ist eine Member-Methode
...Das klingt ja alles sehr schön .... aber kennst Du außer Dir noch jemanden, der das so sieht ?
Gruß,
Simon2.
-
pktm schrieb:
..
Und in Prolog hab ich das damals so gemacht, dass ich mir gemerkt habe, in welchem Kontext eine Kante in die Chart eingetragen wurde um die implizite Kanten-Repräsentation umzusetzen.
...Also "Kontext" ist doch eigentlich immer nur ein Euphemismus für "globale Variable" - in der Hoffnung, dass man mit dem Namen auch deren Probleme ablegen könnte.
Mach's doch mit globalen Variablen, wenn's sein muss - ich würde einen Parameter vorziehen (und sei es nur in separaten Aufruffunktionen oder einem anderen Parameter gekapselt).Gruß,
Simon2.
-
Simon2 schrieb:
pktm schrieb:
..
Und in Prolog hab ich das damals so gemacht, dass ich mir gemerkt habe, in welchem Kontext eine Kante in die Chart eingetragen wurde um die implizite Kanten-Repräsentation umzusetzen.
...Also "Kontext" ist doch eigentlich immer nur ein Euphemismus für "globale Variable" - in der Hoffnung, dass man mit dem Namen auch deren Probleme ablegen könnte.
Mach's doch mit globalen Variablen, wenn's sein muss - ich würde einen Parameter vorziehen (und sei es nur in separaten Aufruffunktionen oder einem anderen Parameter gekapselt).Gruß,
Simon2.
Nix globale Varibale - pfui! ^^
Das wurde in Prolog auch schön mit einem Parameter gelöst, auch wenn das eher der untypischere Weg war.
-
Wie schön zu sehen, dass mein kleiner Beitrag wieder mal eine Riesendiskussion aufgeworfen hat
camper schrieb:
Nexus schrieb:
Mit Methoden bezeichnet man im Übrigen nur die Funktionen von Klassen und Strukturen (ich sehe bei dir weder noch).
1. Strukturen sind Klassen.
2. Der Begriff "Methode" ist im Kontext von C++ nicht eindeutig, der Standard benutzt dieses Wort nicht. Der Begriff wird primär in der objektorientierten Programmierung gerne verwendet; da C++ nicht rein objektorientiert ist, gibt es dort dafür aber keine exakte Entsprechung. Je nach Kontext könnten nur virtuelle Funktionen, oder sonst nur nicht-statische Memberfunktionen, oder sonst jede Art Memberfunktion, oder sonst jede Memberfunktion und solche freien Funktionen, die mit der Klasse direkt assoziert sind, gemeint sein. Aus diesem Grunde sollte der Begriff hier nur mit Bedacht verwendet werden und jedenfalls kann er nicht so ohne Weiteres auf obige Definition reduziert werden - oder man legt das "von" sehr weit aus.1. Ich bin mir im Klaren darüber, dass struct und class in C++ bis auf die Zugriffsrechte identisch sind, aber kann man sie deshalb nicht namentechnisch trennen? Also "Struktur" für alle mit public als Defaultberechtigung, "Klasse" für jene mit private? Selber brauche ich eigentlich auch eher "Klasse", hier wollte ich betonen, dass es für beide gelte.
2. Danke für die Berichtigung; ich war mir relativ sicher, mit Methode eine Klassen-Memberfunktion zu bezeichnen.
In C++ ist es aber relativ häufig so, dass irgendwelche Bezeichnungen nicht ganz eindeutig sind, oder? Gerade wenn man z.B. von Struktur spricht, kann man neben dem Schlüsselwort struct und dessen Anwendung auch z.B. Programmstruktur, Dateistruktur etc. meinen... Klar muss man das halt eindeutig schreiben, meistens ist es auch aus dem Kontext ersichtlich. Ich denke nur, es gibt einige Begriffe, die sich nicht so leicht definieren lassen.
-
Um auf die eigentliche Fragestellung zurückzukommen: Unter Vernachlässigung einiger weniger Spezialfälle kenne ich nur folgende Möglichkeiten die Sinn machen. (Und Vernachlässigung von allem was mit jetzt u.u. entgangen ist)
- Man übergibt der Funktion alles was sie braucht um zu entscheiden was sie tun muss
- Man macht unterschiedliche Funktionen die unterschiedliche Dinge tun
3a) Man entscheidet anhand von Member-Variablen was zu tun ist
3b) Man entscheidet anhand der konkreten Klasse eines Objekts was zu tun ist
Jede dieser Möglichkeiten kann man gut anwenden, allerdings kommt es sehr darauf an worum es geht. Wo z.B. viel konfiguriert und gescriptet wird wird man um (1) nicht herumkommen. (2) hat ansich keinen eigentlichen "Zweck", sondern ist IMO eher als "Normalzustand" anzusehen bzw. anzustreben. Und (3) ist bei Objektorientierter Programmierung oft angesagt, z.B. immer dort wo man Programmteile hat die mit einem abstrakten Interface arbeiten.
Globale Variablen sind IMO böse, und sollten vermieden werden solange nicht sehr gute Gründe für deren Einsatz sprechen. Und das tun sie wie Anfangs angedeutet nur ganz selten.
-
hustbaer schrieb:
Um auf die eigentliche Fragestellung zurückzukommen: Unter Vernachlässigung einiger weniger Spezialfälle kenne ich nur folgende Möglichkeiten die Sinn machen. (Und Vernachlässigung von allem was mit jetzt u.u. entgangen ist)
Mit anderen Worten:
Unter Vernachlässigung dessen, was ich nicht weis, kenne ich folgende Möglichkeiten:
-
pktm schrieb:
So wird es halt ein Parameter.
ja.
-
Simon2 schrieb:
Also "Kontext" ist doch eigentlich immer nur ein Euphemismus für "globale Variable" - in der Hoffnung, dass man mit dem Namen auch deren Probleme ablegen könnte.
In diesem Sinne habe ich das Wort noch nie verstanden. Alles was ich programmiere lebt normalerweise in einem gewissen Kontext, darunter fällt für mich jeglicher Programmzustand von dem die Ausführung einer Funktion (oder Methode ;)) abhängt. Wo kommen da jetzt die globalen Variablen ins Spiel?
-
Jester schrieb:
Simon2 schrieb:
Also "Kontext" ist doch eigentlich immer nur ein Euphemismus für "globale Variable" - in der Hoffnung, dass man mit dem Namen auch deren Probleme ablegen könnte.
In diesem Sinne habe ich das Wort noch nie verstanden. Alles was ich programmiere lebt normalerweise in einem gewissen Kontext, darunter fällt für mich jeglicher Programmzustand von dem die Ausführung einer Funktion (oder Methode ;)) abhängt. Wo kommen da jetzt die globalen Variablen ins Spiel?
Ja und der Wertekontext der CDU hat auch nichts mit globalen Variablen zu tun.... :p
Ich kenne den Ausdruck "Kontext" (u.a.) aus folgendem Kontext: "Ja ... und woher weiß jetzt das Objekt, in welchem Subsystem es liegt ? ... ach, das kann es ja aus dem 'Kontext' lesen !" ... und damit ist dann eine bestimmte technische Datenstruktur gemeint, die von überall zugänglich ist.
So ein Vorgehen hatte ich beim Threadersteller vermutet, aber das hat er ja bereits weiter oben widerlegt.Gruß,
Simon2.
-
das heißt dein "eigentlich immer" ist zu lesen als "auch manchmal"?
-
Jester schrieb:
das heißt dein "eigentlich immer" ist zu lesen als "auch manchmal"?
Nein, sondern es heißt "... in meinem Umfeld und in solchen Fragestellungen eigentlich immer ...".
Hätte jetzt nicht gedacht, dass das sooo außergewöhnlich ist.Gruß,
Simon2.
