OOP: soll man jetzt alles in ne Klasse packen oder watt?

[Gregor]

Zeus schrieb:

Im gegensatz zu Java werden Schnittstellen als formale Beschreibung beschriben, diese werden mit eine Ableitung konkrete implementiert.

Ok. Wo ist das "formale" daran? Formal heißt für mich in jedem Fall, dass ich ein Sprachmittel zur Verfügung habe, mit dem ich sagen kann: "Das da ist eine Schnittstelle!". Wie ist das in C++ gegeben? Wo ist denn die formale Schnittstellendefinition von swap?

[Zeus]

lol sry vertipper in text

sollte heissen:
"In Java hingegen"

Java hat die Sprachmittel
- Interface-Keyword und
- Implements-Keyword

[Gregor]

Zeus schrieb:

lol sry vertipper in text

sollte heissen:
"In Java hingegen"

Java hat die Sprachmittel
- Interface-Keyword und
- Implements-Keyword

Ah, ok. Kannst Du nochmal die Stelle im Stroustrup angeben, wo erklärt wird, was ne Schnittstelle bei C++ ist?

[Shade Of Mine]

Ist das nicht viel zu theoretisch und schon eher philosophisch?

Mir ist es eigentlich egal ob es jetzt laut irgendeiner definition als Interface durchgeht oder ich es Pseude-Interface nennen muss.

Worum es geht ist, dass man auf diese Art und Weise genauso abstrakte Aktionen fuer ein Objekt definieren kann wie mit herkoemmlichen Interfaces.

In C++ hat man sowieso viele "Memberfunktionen" ausserhalb der Klasse. Aber zB ein getline() gehoert fuer mich zur Schnittstelle von string.

Schaut euch mal lisp an. Da hat man Objekte komplett ohne Klassen. Da hat man im Prinzip nur eine sammlung von globalen funktionen. Und dennoch hat man OO. In C kann ich auch OO arbeiten - natuerlich fehlen hier viele buildin features von besser ausgepraegten OO sprachen wie zB virtuelle methoden, aber auch dennoch kann ich OO programmieren. Und dann ist das Interface einer Klasse eine sammlung an globalen Funktionen.

Ist natuerlich etwas komplett anderes als das herkoemmliche 08/15 OOP, aber nur weil ich sqrt(a) statt a.sqrt() schreibe ist es doch noch lange nicht etwas komplett anderes...

[Zeus]

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.

[check es endlich]

an sqrt(a) ist nichts objektorientiert, es ist rein funktional
a.sqrt() ist objektorientiert, weil der momentane zustand des objekts a berücksichtigt wird

[ooo]

a.sqrt() ist objektorientiert weil es eine Memberfunktion einer Klasse verwendet.

[Zeus]

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

[Gregor]

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.

[Shade Of Mine]

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.

[Möpschen]

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.

[Zeus]

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

[byto]

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.

[volkard]

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.

[Zeus]

Doch ISO/IEC 2382-15 (1998)

[volkard]

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".

[Orientierungsloser]

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?

[Gregor]

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

[Zeus]

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.

[Zeus]

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