OOP: soll man jetzt alles in ne Klasse packen oder watt?
-
Gregor schrieb:
Ah, ok. Kannst Du nochmal die Stelle im Stroustrup angeben, wo erklärt wird, was ne Schnittstelle bei C++ ist?
S.180 .... wie gesagt, ne richtige Definition ist das leider nicht, aber man kann es ersehen.
-
an sqrt(a) ist nichts objektorientiert, es ist rein funktional
a.sqrt() ist objektorientiert, weil der momentane zustand des objekts a berücksichtigt wird
-
a.sqrt() ist objektorientiert weil es eine Memberfunktion einer Klasse verwendet.
-
Bitte hört auf.
Memberfunktion sind Funktionen die an Objekte gebunden sind.
Klassenfunktionen sind Funktioen die an Klassen gebunden sind, also unsere lieben statische Funktion.Btw:
Klassenfunktionen können sehr wohl über ein Objekt aufgerufen werden. Die Auflösung ist sehr leicht zu realisieren (siehe C#).Python:
sqrt(self) ist aber Objektorientiert....
-
check es endlich schrieb:
an sqrt(a) ist nichts objektorientiert, es ist rein funktional
Ich glaube, in diesem Thread geht es insgesamt nicht so sehr um OOP. Also lassen wir den Aspekt besser mal weg. Die Frage ist doch eher, ob eine Gruppierung ähnlicher Funktionalität, wie Shade sie vorschlägt (alle sqrt's in std oder so), gegenüber einer Bindung der Funktionalität an irgendwelche Typen sinnvoll ist. Wenn man diese Vorgehensweise weiterdenkt, kommt man vermutlich zu dem, was hier mal als "Methodenorientierte Programmierung" vorgeschlagen wurde. Die grundsätzliche Frage ist hier also vielleicht am ehesten "OOP vs. MOP".
Hmmm... wenn ich so darüber nachdenke... das interessiert mich nicht.
Ich glaube, das ist ziemlich weit abseits des eigentlichen Themas des Threads. ...für diese MOP-Richtung ist eine Erweiterbarkeit von Namespaces (oder anderer Sprachmittel, die man zur Gruppierung nutzt) vielleicht relativ wichtig und sinnvoll, das sehe ich ein. Ob MOP insgesamt sinnvoll ist, ist ne andere Frage. Zumindest bietet auch C++ AFAIK keine wirklichen Sprachmittel, um MOP zu unterstützen. So ein Namespace ist da ein Hilfskonstrukt.@Shade: Ich habe eigentlich auch keine Lust mehr auf diesen Thread und klinke mich deshalb an dieser Stelle aus der Diskussion aus. Ich habe das Gefühl, dass wir ziemlich stark aneinander vorbeigeredet haben. Sorry, falls ich'n bischen schwer von Begriff war.
-
Es ist Objektorientiert.
OOP hat nichts mit Klassen zu tun.
Und wie schon mehrmals gesagt: in C++ macht man das so. Das wurden von klugen Koepfen so ausgedacht. In C++ definiert sich das Interface einer Klasse eben nicht nur aus den direkten Memberfunktionen, sondern auch aus den passenden globalen Funktionen:
zB gehoert getline() zu std::string dazu. der operator+ gehoert zu std::string,... Obwohl sie keinen direkten Member sind.
-
MOP ist top.
Der Gedanke, ich mach etwas, und erstmal ist egal, womit. Dann kann man sqrt mit allem Möglichen implementieren, und alle Adapter für ale Objekte sind im gleichen package, dem sqrt.
Leider gibt es nur eine Sprache (Cmol) und einen Compiler, und leider benutzt es niemand. Aber es ist sehr interessant.
-
Definition von OOP der Uni Potsdam schrieb:
Ein Objekt ist ein allgemeiner Datentyp, der Daten mit Funktionen kombinieren und bearbeiten kann. Die Daten eines Objektes sind seine Eigenschaften . Funktionen, die diese Eigenschaften bearbeiten können, nennt man Methoden der Objekte.
Eine Klasse ist eine Sammlung aller Eigenschaften und Methoden der Objekte dieser Klasse und legt fest, wie diese zu erzeugen sind. Eine Instanz einer Klasse ist ein anderes Wort für ein tatsächliches Objekt. Während Klassen eine abstrakte Darstellung eines Objekts sind, ist eine Instanz dessen konkrete Darstellung.Quelle: http://ddi.cs.uni-potsdam.de/HyFISCH/Produzieren/SeminarDidaktik/OOP/OOPBegriffe.html#top
-
Shade Of Mine schrieb:
Und wie schon mehrmals gesagt: in C++ macht man das so. Das wurden von klugen Koepfen so ausgedacht. In C++ definiert sich das Interface einer Klasse eben nicht nur aus den direkten Memberfunktionen, sondern auch aus den passenden globalen Funktionen.
C++ kombiniert den objektorientierten Ansatz mit dem prozeduralen, weil globale Funktionen eben nicht im Sinne der OOP sind. Das gleiche gilt im übrigen für (öffentliche) statische Methoden in Java. Beide Sprachen sind demnach nicht zu 100% objektorientiert ausgelegt. Wenn Du das nicht verstehen willst, dann solltest Du vielleicht nochmal nachlesen, wie sich die OOP definiert.
-
byto schrieb:
Wenn Du das nicht verstehen willst, dann solltest Du vielleicht nochmal nachlesen, wie sich die OOP definiert.
es gibt keine allgemein anerkannte definition von OO.
-
Doch ISO/IEC 2382-15 (1998)
-
Zeus schrieb:
Doch ISO/IEC 2382-15 (1998)
also
Eine Technik oder Programmiersprache betreffend, die Objekte, Klassen und Vererbung unterstützt.
unfug. zwar nett gemeint, aber kein treffer.
Allerdings gibt es eine Anmerkung in ISO/IEC 2382-15 (1998), die erwähnt, daß „einige Autoritäten“ Informationsschutz, Kapselung, Datenabstraktion, Nachrichtenvermittlung, Polymorphismus, dynamische Bindung oder Vererbung verlangen.
ok, nehmen wir mal hin. was ist mit den klassen?
schauen wir mal nach Self und wundern uns. http://research.sun.com/techrep/1994/smli_tr-94-30.pdf#search="self power of simplicity"
bleibt also übrig:Eine Technik oder Programmiersprache betreffend, die Objekte unterstützt.
oder viel viel besser "man programmiert objektorientiert, wenn man sich beim programmieren an objekten orientiert".
-
volkard schrieb:
oder viel viel besser "man programmiert objektorientiert, wenn man sich beim programmieren an objekten orientiert".
In einem Sazt auf den Punkt gebracht. Warum Seiten lang streiten?
-
...um mich doch noch mal kurz einzumischen...
volkard schrieb:
oder viel viel besser "man programmiert objektorientiert, wenn man sich beim programmieren an objekten orientiert".
Ok, damit bin ich voll und ganz einverstanden. Aber kannst Du mal erklären, inwiefern eine Gruppierung von Funktionen nach der Funktionalität eine Orientierung an Objekten darstellt? Für mich sieht das eher so aus, als ob da die Funktionalität im Zentrum steht. Deswegen habe ich MOP ins Gespräch gebracht.
-
Ok, ISO/IEC 2382-15 sollst nicht sein, ehrlich gesagt mir ist das egal.
Aber wenn man von Programmiersprachen redet, sollte sich mal sein Vokabular so wählen, dass die Semantik dahinter nicht durcheinandere wirft.
Massgeblich für Definitionen sind für mich Standardisierungsgremien, Unis oder gänige Literatur.
-
Orientierungsloser schrieb:
volkard schrieb:
oder viel viel besser "man programmiert objektorientiert, wenn man sich beim programmieren an objekten orientiert".
In einem Sazt auf den Punkt gebracht. Warum Seiten lang streiten?Weil OOP mehr ist als dieser Satz ist.
[]Kapselung von Methoden und Daten
[]Polymorphie
[*]Vererbung
...
-
Gregor schrieb:
...um mich doch noch mal kurz einzumischen...
volkard schrieb:
oder viel viel besser "man programmiert objektorientiert, wenn man sich beim programmieren an objekten orientiert".
Ok, damit bin ich voll und ganz einverstanden. Aber kannst Du mal erklären, inwiefern eine Gruppierung von Funktionen nach der Funktionalität eine Orientierung an Objekten darstellt? Für mich sieht das eher so aus, als ob da die Funktionalität im Zentrum steht. Deswegen habe ich MOP ins Gespräch gebracht.
Absolute Zustimmung. Das Problem mit sqrt() liesse sich perfekt MO implementieren. Hat mit OO einfach nichts zu tun. Methoden sind schliesslich für spezielle Klasseneigenschaften. Für Funktionen, die mit mehreren verschiedenen Klassen funktionieren sollen, fehlt in der OOP eine geeignete Lösung, egal in welcher Sprache. Und darum ist die Disskusion irgenwie mühsig.
Infos: http://c-mol.mosd.net/de/docs.html
-
Gregor schrieb:
...um mich doch noch mal kurz einzumischen...
volkard schrieb:
oder viel viel besser "man programmiert objektorientiert, wenn man sich beim programmieren an objekten orientiert".
Ok, damit bin ich voll und ganz einverstanden. Aber kannst Du mal erklären, inwiefern eine Gruppierung von Funktionen nach der Funktionalität eine Orientierung an Objekten darstellt? Für mich sieht das eher so aus, als ob da die Funktionalität im Zentrum steht. Deswegen habe ich MOP ins Gespräch gebracht.
Absolute Zustimmung. Das Problem mit sqrt() liesse sich perfekt MO implementieren. Hat mit OO einfach nichts zu tun. Methoden sind schliesslich für spezielle Klasseneigenschaften. Für Funktionen, die mit mehreren verschiedenen Klassen funktionieren sollen, fehlt in der OOP eine geeignete Lösung, egal in welcher Sprache. Und darum ist die Disskusion irgenwie mühsig.
Infos: http://c-mol.mosd.net/de/docs.html
-
Gregor schrieb:
...um mich doch noch mal kurz einzumischen...
volkard schrieb:
oder viel viel besser "man programmiert objektorientiert, wenn man sich beim programmieren an objekten orientiert".
Ok, damit bin ich voll und ganz einverstanden. Aber kannst Du mal erklären, inwiefern eine Gruppierung von Funktionen nach der Funktionalität eine Orientierung an Objekten darstellt?
aber gerne. die oo findet im kopf statt. es ist doch wurstegal, ob ich ich.schlage(hund) oder schlage(ich,hund) dann aufschreibe. man kann auch in assembler objektorientiert programmieren und in c++ und java ganz darauf verzichten.
und objekte müssen nicht zwangsläufig instanzen eigener klassen sein. mangels schreibenkönnens von 5.sqrt() schreiben wir halt std::sqrt(5), ist aber voll in ordnung, weil der compiler genau wie bei 5.sqrt() am subjekt vor dem verb bei std::sqrt(5) am ersten objekt (das ist netterweise das subjekt) erkennt, welche sqrt genau zu verwenden ist.
die gruppierung in std:: hat nur codeverwaltungstechnische ziele, man könnte statt std::sqrt(5) auch gerne dasNormaleSqrt(5) oder einfach sqrt(5) nehmen. also hats gruppieren in std:: nix mit objektorientierung zu tun. das rausstellen als globale funktion ist gute objektorientierung, genauso wie das anbieten als methode.
die gruppierung in Math. hat nur codeverwaltungstechnische ziele, man könnte statt Math.sqrt(5) auch gerne dasNormaleSqrt(5) oder einfach sqrt(5) nehmen. also hats gruppieren in Math. nix mit objektorientierung zu tun. das rausstellen als globale funktion ist gute objektorientierung, genauso wie das anbieten als methode. wenn man beides nicht kann, erklärt man einfach die klassse zu einem standardnamespace udn erklärt damit die Math.sqrt zu rausgestellten globalen funktion. in anderen sprachen muß man noch viel schlimmere umwege gehen.
das problem am thread ist die alte leier "java ist eine 100%-oo-sprache und darum total gut". das muß man einfach als marketinglüge aufdecken (hiermit geschehen). bereits eine sprache als oo sprache zu verkaufen, grenzt an betrug. das ist, wie wenn man einen genau treffenden hammer verkauft. das werkzeug kann nur ganz wenig beisteuern, ob ich dem doofi, der sich bereiterklärt, den nagel für mich zu halten, auf den daumen haue. und dann noch zu erklären, der hammer würde genauer treffen, weil man mit ihm nur nägel einschlagen kann, aber keine wieder ruasziehen, ist absurd.
daher auch die viele heiße luft, die energie für einen so langen thread lieferte.
-
Zeus schrieb:
Massgeblich für Definitionen sind für mich Standardisierungsgremien, Unis oder gänige Literatur.
ich gestatte hingegen mir den luxus, gelegentlich selber zu denken.