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

volkard schrieb:

Möpschen schrieb:

Für Funktionen, die mit mehreren verschiedenen Klassen funktionieren sollen, fehlt in der OOP eine geeignete Lösung, egal in welcher Sprache.

a) du meinst, wenn man window.close() und socket.close() und button.close() anbietet, ist das ungeeignet?
b) du meinst, wenn man close(window) und close(socket) und close(button) anbietet, ist das ungeeignet?
oder ganz was anderes?

Nein, ich meine...Momentchen, Du hast meinen Link nicht verfolgt, schade

c) close.window(myWindow) und close.socket(mySocket) und close.button(myButton) hielte ich für geeignet und logisch. (Oder so ähnlich, aber die Syntax ist dabei zweitrangig)

rüdiger

Zeus schrieb:

DEvent schrieb:

double eingabe(tastatur t) { return tastatureingabe; };

double sqrt(double x) { return wurzel aus x; }; 

double ausgabe(double x) { gib x auf Monitor aus; }

int main()
{
    double x = eingabe(tastatur);
    double y = sqrt(x);
    ausgabe(y);
}

Und was mach ich wenn ich ne eingabe über ne maus haben will?

double eingabe(maus);

Wo ist das Problem

Shade Of Mine

Gregor schrieb:

Also eigentlich ist das keine Definition, sondern ein schlechter Witz. Das ist ungefähr so:

"Definiere Blau!"

Definition Blau: Blau ist blau.

naja, worum es geht ist, dass du keine Klassen brauchst.

Beispiel Java \1:
es gibt keine Klassen und keine vererbung.

dennoch baue ich damit objekt orientierte loesungen und die sind sogar sauber. ich habe viele OO features, zB hat jedes objekt methoden die ich aufrufen kann. ich kann die methoden sogar ueberschreiben und neue hinzufuegen. und alles ist ein objekt. sogar funktionen und so...

also eindeutig eine sprache die objekt orientierte programmierung unterstuetzt. aber keine klassen hat.

Shade Of Mine

Möpschen schrieb:

c) close.window(myWindow) und close.socket(mySocket) und close.button(myButton) hielte ich für geeignet und logisch. (Oder so ähnlich, aber die Syntax ist dabei zweitrangig)

nein. das laeuft nicht.

beispiel: es gibt socket und async_socket.

ich habe nun einen socket und will diesen schliessen, aber ka ob es ein async oder normaler ist.

also mache ich:
close(sock);
oder
sock.close();

ein
close.???(sock);
geht natuerlich nicht...

Gregor

Shade Of Mine schrieb:

naja, worum es geht ist, dass du keine Klassen brauchst.

Beispiel Java \1:
es gibt keine Klassen und keine vererbung.

dennoch baue ich damit objekt orientierte loesungen und die sind sogar sauber. ich habe viele OO features, zB hat jedes objekt methoden die ich aufrufen kann. ich kann die methoden sogar ueberschreiben und neue hinzufuegen. und alles ist ein objekt. sogar funktionen und so...

also eindeutig eine sprache die objekt orientierte programmierung unterstuetzt. aber keine klassen hat.

ok, ok... hier wird ja andauernd gesagt, was OOP nicht ist. OOP hat nichts mit Klassen zu tun, OOP hat nichts mit Vererbung zu tun, OOP hat nichts mit Polymorphie zu tun, OOP hat nichts mit Kapselung zu tun usw.. Oder zumindest braucht man nichts davon um objektorientiert zu programmieren.

Gehen wir mal nen anderen Weg und überlegen uns, was OOP eigentlich ist. Wie könnte man da raungehen? Mal ein naiver Ansatz: Gucken wir doch einfach mal in der wikipedia nach und stellen das zur Diskussion:

http://de.wikipedia.org/wiki/Objektorientierte_Programmierung

Die Grundidee der objektorientierten Programmierung ist, Daten und Funktionen, die auf diese Daten angewendet werden können, möglichst eng in einem sogenannten Objekt zusammenzufassen und nach außen hin zu kapseln, sodass Methoden fremder Objekte diese Daten nicht versehentlich manipulieren können.

So. Jetzt ging es aber die ganze Zeit darum, eine Gruppierung der Funktionen nach der Funktionalität als OOP zu bezeichnen. Mit anderen Worten: Es geht darum, eine separation von Daten und Funktionen als OOP zu bezeichnen.

Guck Dir den Satz da oben aus der Wikipedia-Definition an und sag mir, wie das zusammenpasst. Ach, lass es. Ich sag es Dir: Das passt gar nicht zusammen. Was Ihr da betreibt ist keine OOP.

Ok, Du wirst sagen, der Wikipedia-Artikel ist ideologisch gefärbt. Gib mir eine andere Quelle, die eine vernünftige OOP-Definition beinhaltet, die eure Vorgehensweise beinhaltet. Vermutlich wirst Du feststellen, dass die ganze Welt einen völlig falschen OOP Begriff hat.

Bashar

Gregor schrieb:

Die Grundidee der objektorientierten Programmierung ist, Daten und Funktionen, die auf diese Daten angewendet werden können, möglichst eng in einem sogenannten Objekt zusammenzufassen und nach außen hin zu kapseln, sodass Methoden fremder Objekte diese Daten nicht versehentlich manipulieren können.

Mit Wikipedia ist das ja immer so eine Sache... Du weißt nicht, wer das da geschrieben hat, ob das fundiert ist usw. Da sich diese angebliche Grundidee eher nach der Grundidee der modularen Programmierung anhört, kann das schonmal nicht ganz stimmen. Und dieser Punkt, dass die Grundidee irgendwas mit versehentlichem Manipulieren zu tun haben soll ist ja wohl auch nicht wirklich ernstzunehmen (vielleicht hat da jemand Bertrand Meyer gelesen und denkt jetzt, dass dessen Ideen zu Objekt == Modul tatsächlich die Grundideen der OOP darstellen.)
Meines Wissens ist die Grundidee von OOP, dass Daten in Objekte zusammengefasst werden, die untereinander Nachrichten austauschen. Die Kapselung (ein Objekt muss keine Nachricht verarbeiten, die es bittet, seine Interna offenzulegen, du kannst nur an die Subobjekte Nachrichten schicken, die das Objekt auch herausgeben will) und die Polymorphie (alle Objekte, die eine bestimmte Nachricht verstehen, sind an der entsprechenden Programmstelle prinzipiell austauschbar) folgen daraus. Da steht noch kein Klassenbegriff und noch keine Vererbung. Die Klassen sind eine Möglichkeit, dieses Konzept zu implementieren, Prototypen sind eine andere.

Mit der Idee erschlägst du sämtliche Single-Dispatch-OOP-Sprachen mit einmal. CLOS passt nicht so ganz rein, da müsste man mal über die Geschichte der Lisp-Objektsysteme forschen.

rüdiger

@Gregor
Angenommen wir gehen von dieser Definition aus, ignorieren wie einmal die Schwächen die Bashar aufgezeigt hat, so sehe ich immer noch nicht, warum folgendes nicht der Definition entsprechen sollte:

struct foo;

void bar(foo const &obj);

oder so etwas wie das Lisp Beispiel von mir.

@Bashar

Zeus

Die Abstraktion von Objekten kommt bisschen kurz, aber in ganzen wiederspricht es nicht von allen Erkläuterungen von OOP, die ich je gelesen habe.

Zeus

rüdiger schrieb:

@Gregor
Angenommen wir gehen von dieser Definition aus, ignorieren wie einmal die Schwächen die Bashar aufgezeigt hat, so sehe ich immer noch nicht, warum folgendes nicht der Definition entsprechen sollte:
struct foo;

void bar(foo const &obj);
oder so etwas wie das Lisp Beispiel von mir.

@Bashar

Es ist eine Funktion die als Paramter eine Datenstruktur aufnimmt.
Was soll daran OOP sein?

Nur weil man als Bezeichner obj wählt, macht es automatisch eine OOP.

rüdiger

Zeus schrieb:

Es ist eine Funktion die als Paramter eine Datenstruktur aufnimmt.
Was soll daran OOP sein?

Es ist eine Nachricht (Methode), die an ein Objekt gesendet wird. Was soll daran nicht OOP sein? Widerspricht der Definition in keinster Weise. Ansonsten zeig es mir auf.

Shade Of Mine

Zeus schrieb:

Nur weil man als Bezeichner obj wählt, macht es automatisch eine OOP.

welchen aspekt den du unter OOP verstehst widersprichst dieser code?

DEvent

rüdiger schrieb:

Zeus schrieb:

DEvent schrieb:

double eingabe(tastatur t) { return tastatureingabe; };

double sqrt(double x) { return wurzel aus x; }; 

double ausgabe(double x) { gib x auf Monitor aus; }

int main()
{
    double x = eingabe(tastatur);
    double y = sqrt(x);
    ausgabe(y);
}

Und was mach ich wenn ich ne eingabe über ne maus haben will?

double eingabe(maus);

Wo ist das Problem

Habt ihr Tomaten auf den Augen ? Soll das etwa OOP sein ?

Das ist stinknormale prozedurale Programmierung.
Schaut mal nach: http://de.wikipedia.org/wiki/Programmierparadigma#Prozedurale_Programmierung
Nur weil hier Objekte wie double, tastatur, auftauchen, nennt ihr das Objectorientiert ?

Es ist eine Nachricht (Methode), die an ein Objekt gesendet wird. Was soll daran nicht OOP sein? Widerspricht der Definition in keinster Weise. Ansonsten zeig es mir auf.

Weil kein Objekt da ist zu dem eine Nachricht geschickt wird ?

object.nachricht(daten);

So sieht es normalerweise aus.

prozedurfunktion(object, daten);

Das ist stinknormale prozedurale Programmierung. Das hatten wir schon mit Pascal, C, usw.
Diese Methode bietet keinerlei Vorteile, die aber eine OOP normal bietet (abstraktion der Daten, Kapselung, Vererbung, usw)

Gregor

Bashar schrieb:

Meines Wissens ist die Grundidee von OOP, dass Daten in Objekte zusammengefasst werden

Ne. Aus meiner Sicht ist die Grundidee der OOP, wie es in dem Artikel da steht, dass Daten UND FUNKTIONEN in Objekten zusammengefasst werden. Da ist es ziemlich egal, ob man dafür ein Klassenkonstrukt verwendet. Das wichtige ist, dass Daten und Funktionen nach beieinander liegen. ...und zwar nicht nur in volkards Kopf, sondern auch im Code. Wenn man die Daten von den Funktionen trennt, wie es Shade mit seiner Gruppierung von Funktionen nach deren Funktionalität implizit vorschlägt, dann ist das etwas, was prinzipiell gegen die Idee der Objektorientierung gerichtet ist. Mir ist immer noch nicht ansatzweise klar, wie man das dann OOP nennen kann.

Shade Of Mine

DEvent schrieb:

Habt ihr Tomaten auf den Augen ? Soll das etwa OOP sein ?

Das ist stinknormale prozedurale Programmierung.
Schaut mal nach: http://de.wikipedia.org/wiki/Programmierparadigma#Prozedurale_Programmierung
Nur weil hier Objekte wie double, tastatur, auftauchen, nennt ihr das Objectorientiert ?

ist das etwa deine art zu argumentieren?

dir ist schon klar dass du hier nicht mit irgendwelchen moechte gern noobs redest, oder?

implementier das ganze mal mit klassen und nenne mir dann die vorteile von der methode mit klassen. eins ist wie gesagt dynamische polymorphie - aber nur deshalb weil C++ keine multi methods hat.

Weil kein Objekt da ist zu dem eine Nachricht geschickt wird ?

da ist ein objekt. nur weil da nicht klasse steht. oder wie definierst du objekt?

eine sammlung von attributen und aktionen.
die attribute sind halt public und die aktionen sind die funktionen.
passt doch.

oder was braucht ein objekt deiner meinung nach noch?

zB FILE* aus C. man kann halt nicht ableiten davon, betrachten wir es eben als sealed. und wir haben private daten und oeffentliche methoden.

Diese Methode bietet keinerlei Vorteile, die aber eine OOP normal bietet (abstraktion der Daten, Kapselung, Vererbung, usw)

abstraktion haben wir, ich kann tastatur eingabe durch maus ersetzen, ohne probleme.

kapselung ist auch gegeben, ich definiere accessor fuer die struct member und sage man darf sie nicht direkt setzen. in c++ sage ich das ja auch, denn ich kann jederzeit ja #define private public machen...

und vererbung: wie gesagt, es gibt sprachen ohne klassen, zB javascript. und ohne klassen halt keine herkoemmliche vererbung. ist javascript deiner meinung nach eine objekt orientierte sprache?

Shade Of Mine

Gregor:

liegen doch beieinander.

direkt untereinander im code.
keine andere code zeile ist dazwischen.

was willst du mehr?

Zeus

Ich bin greade beim entgleissen greade, wie Ihr Begriffe aus der prozedurale Programmierung auf Begriffe der objektorientierte mapped.

finix

DEvent schrieb:

Weil kein Objekt da ist zu dem eine Nachricht geschickt wird ?
object.nachricht(daten);
So sieht es normalerweise aus.
prozedurfunktion(object, daten);

Syntax != Semantik.

Zeus

finix schrieb:

DEvent schrieb:
Weil kein Objekt da ist zu dem eine Nachricht geschickt wird ?
object.nachricht(daten);
So sieht es normalerweise aus.
prozedurfunktion(object, daten);
Syntax != Semantik.

Ja ist uns schon klar, trotzdem kann man von prozedurfunktion(object, daten) nix ableiten also kein OOP.

Gregor

Shade Of Mine schrieb:

implementier das ganze mal mit klassen und nenne mir dann die vorteile von der methode mit klassen.

Ich glaube, es geht in dieser Diskussion nicht so sehr um Vor- und Nachteile bestimmter Codestücke, sondern eher nur um die Zuordnung bestimmter "Designs" usw. zu unterschiedlichen Programmierparadigmen.

Shade Of Mine schrieb:

und vererbung: wie gesagt, es gibt sprachen ohne klassen, zB javascript. und ohne klassen halt keine herkoemmliche vererbung. ist javascript deiner meinung nach eine objekt orientierte sprache?

All diese Konzepte, zu denen auch die Vererbung gehört, sind sicherlich nicht zwingend für die OOP nötigt. Dennoch ordnet man diese Konzepte der OOP zu. Insofern kann man sicherlich sagen, dass eine Sprache, die diese Konzepte besser als eine andere Sprache unterstützt/ermöglicht, auch die OOP stärker unterstützt. Du kommst ja auch nicht auf die Idee, Prolog als objektorientierte Sprache zu bezeichnen, nur weil volkard gesagt hat, dass man ja auch in Prolog objektorientiert programmieren kann.

Was man sich fragen sollte, ist doch: Wie sieht objektorientierte Programmierung aus, wenn man keine passenden Sprachmittel zur Verfügung hat. Die Antwort ist, dass man sich da Abhilfe schaffen muss. Man muss sich irgendwelche Krücken bauen, die einem die objektorientierten Konzepte zur Verfügung stellen, die man nutzen möchte.

Gregor

Shade Of Mine schrieb:

Gregor:

liegen doch beieinander.

direkt untereinander im code.
keine andere code zeile ist dazwischen.

was willst du mehr?

Shade: Code UND KOPF, habe ich doch gesagt! Die Platzierung der verschiedenen Elemente, die zu einem Objekt gehören, in unteschiedlichen Namensräumen, zeigt mir, dass Du sie im Kopf nicht so anordnest. Du setzt im Prinzip unterschiedliche "Überschriften" über die verschiedenen Elemente. Und unter diesen "Überschriften" findet sich eben auch alles mögliche, was mit dem Objekt nichts zu tun hat. Für mich heißt das: "Ja, ok, ich habe das zwar untereinandergeschrieben, aber das mein ich ja gar nicht so....".