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

[Bashar]

volkard schrieb:

ich kenne keine sprache mit dem arithmetischen operator +, wo + nicht polymorh ist und doubles ganz anders addiert als integers (oder gar strings).

Dann verweise ich dich mal auf Ocaml. + ist strikt für integer, der entsprechende Operator für real heißt +. (Plus-Punkt).

[volkard]

Gregor schrieb:

volkard: Ok, es gibt ja nun diverse Konzepte, die man mit OOP assoziiert, die aber alle nicht unbedingt dazugehören müssen. Da wurde ja jetzt ne ganze Menge genannt. C++ bietet praktisch für alle diese Konzepte Sprachmittel zur Unterstützung an. Das was Du hier die ganze Zeit als OOP verteidigst, nutzt allerdings keins dieser Sprachmittel. Ist das nicht komisch? Das kommt mir ungefähr so vor: Du willst nen Nagel einschlagen und hast nen vollen Werkzeugkoffer vor Dir. Was nimmst Du aber, um den Nagel einzuschlagen? Nicht den Hammer, sondern die Säge. Da stimmt doch irgendetwas nicht.

vielleicht können wir uns drauf einigen, daß ich ein elektisches nagelschussgerät verwende. passt zwar nur für diese spezielle arbeit, ist aber cool. und wird in keiner allgemeinen was-ein-werkzeugkasten-haben-sollte-liste aufgeführt.

Meinst Du, die Sprachmittel, die C++ zur Unterstützung der OOP bietet, sind alle nicht passend? Da scheint ja ein riesiger Designfehler in der Sprache vorzuliegen.

denke kaum, daß man es dem hammer als fehler auslegen sollte, daß zufällig ein nagelschussgerät auch greifbar ist. ich arbeite mit dem gerät auch sehr schön nagelorientiert. einschränkung der mittel auf nur die, die in allgemeinen werkzeugkistendefinitionen stehen, wäre doch nicht extrem klug. natürlich kann man oo programmieren auch unter heranziehung weiterer und ganz ganz weiterer sprachmittel.

ist 5+5 oo?
du kannst nicht auf eine zeile code schauen und feststellen, ob sie oo ist. im kontext mit den anderen sachen kann man auf keinen fall sagen, das anbieten eines globalen swap(Bitmap&,Bitmap&) sei weniger oo als ein Swappable-Interface. ihr versucht mir aber dauerd, das einzureden. warum? nur weil's nicht nach java aussieht? eil kein . im aufruf steht? weil die swap-funktion formal keine methode ist? weil es statische polymorphie ist? oder nur, weil ihr es nicht gewohnt seid? ich kann es nicht nachvollziehen. globale funktionen sind weder automatisch schlecht noch automatisch unobjektorientiert.

[Gregor]

volkard schrieb:

ist 5+5 oo?
du kannst nicht auf eine zeile code schauen und feststellen, ob sie oo ist. im kontext mit den anderen sachen kann man auf keinen fall sagen, das anbieten eines globalen swap(Bitmap&,Bitmap&) sei weniger oo als ein Swappable-Interface. ihr versucht mir aber dauerd, das einzureden. warum? nur weil's nicht nach java aussieht? eil kein . im aufruf steht? weil die swap-funktion formal keine methode ist? weil es statische polymorphie ist? oder nur, weil ihr es nicht gewohnt seid? ich kann es nicht nachvollziehen. globale funktionen sind weder automatisch schlecht noch automatisch unobjektorientiert.

Ich habe schon weiter oben gesagt, dass es mir hier nicht auf das Aussehen dieser Zeile ankommt. Was mir persönlich wichtig ist, ist die Organisation des Codes. ...das Design. Ich habe aus Deinen Äußerungen entnommen, dass Du das in keinster Weise nachvollziehen kannst. Naja, ändert aber auch nichts an meiner Sichtweise. Ich glaube, genau das ist hier der zentrale Punkt, über den wir uns sicherlich nicht einig werden.

Du sagst, "OOP ist, wenn man sich an Objekten orientiert" und "Das findet alles im Kopf statt". Nach Deinen Äußerungen ist praktsich alles OOP, wenn da nur einer sagt: "Für mich ist das OOP, weil ich damit ne OO-Vorstellung verbinde.". Das ist mir persönlich einfach zu wenig. Die OOP muss sich IMHO im Code widerspiegeln. Dein OOP Begriff ist aus meiner Sicht völlig schwammig und nutzlos, weil er keine Aussagekraft hat. Er ist ja aus Deiner Sicht nur auf Deine persönliche Sichtweise bezogen. Er kann weder zur Kommunikation noch für sonst irgendetwas produktives zur Hand genommen werden, wenn er sich nicht in konkreten Dingen widerspiegelt.

[Zeus]

Zeus schrieb:

Ich sag Gehen
Du verstehst Schlafen

Ok

oder Du sagst OOP
und wir sehen nur funktionelle Programmierung

#include <iostream>
// "Datenobjekt"
struct Person{
    char[10] name;
    int alter;
    bool isSchwanger;
}

//Schnitstellen
void machLiebe(Person &p, Persion &r = null)(
{
    p.isSchwanger = true;
}
void sterben(Person &p)
{
    delete p;
}

int main()
{
    Person susi, ralf;
    susi.name = "Susi";
    susi.alter = 22;
    susi.isSchwanger = false;
    ralf.name = "Ralf";
    ralf.alter = 24;
    susi.isSchwanger = false;

    machLiebe(susi, ralf);

    sterben(&susi);
    sterben(&ralf);

    return 0;
}

Bitte steinigt mich nicht, hab das nichtmal compiliert
Obwohl ich Person als Objekt sehe, wie im Kommentar geschrieben habe, ist dieser Code nicht Objektorientiert. Man(du oder wer auch immer) mag das verständis zu haben Objekte zu sehen, aber es gibt zwar keine konkrete Definition von OOP, allerdings eine allgemeingültige Ausssage.
Und wenn wir nun darüber sprechen, und uns nicht an diese halten, dann ist es auch kein wunder, dass wir uns über sachen diskutieren, die für jeden andere, nach durchgekauten Kaugummi aussieht.

volkard schrieb:

ist 5+5 oo?

Es ist nur eim mathematische Ausrück nicht mehr und nicht weniger.

Eine OOP-Paradigma muss doch nur:
Objekte definiere -> sei durch Klassen als Vorlagen oder Prototyping wie in Lisp (ich selbst kenn lisp nicht)
von Objekte erben, speziellisung von Objekte erlauben und Nachrichtentypen anpassen auf das eigene Objekte und Datenkapsleung ist leider ein notwendiges ding(Nicht um sonst wird an Perl6 gearbeitet mit private-schlüsselwort).

[volkard]

kommt vielleicht daher, daß ich in basic, c und prolog objektorientiert hab, ohne daß die sprachen mir oo-unterstützung boten. das prog wird nicht duch das benutzen eines typischen oo-sprachmittels oo und wird auch nicht durch vermweidung nicht-oo. jup, das ist schwer zu verstehen und ich muss jetzt leider weg. wenn die zeit reif ist, werdet ihr mir zustimmen.

[finix]

Gregor schrieb:

Die OOP muss sich IMHO im Code widerspiegeln.

Ja, sicher. Aber wie soll/muss das aussehen?

[DEvent]

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);
}

Ist das nicht ein schöner OO-Code ? Ich habe jede Menge Schnittstellen und Objekte, wer sie nicht sehen kann der sollte zum Optiker.

kommt vielleicht daher, daß ich in basic, c und prolog objektorientiert hab, ohne daß die sprachen mir oo-unterstützung boten. das prog wird nicht duch das benutzen eines typischen oo-sprachmittels oo und wird auch nicht durch vermweidung nicht-oo. jup, das ist schwer zu verstehen und ich muss jetzt leider weg. wenn die zeit reif ist, werdet ihr mir zustimmen.

Ist ja schön das du der Oberguru bist und C++ immernoch wie C programmierst, aber es gibt jetzt Sprachmittel für OOP. Also wieso nutzt du sie nicht ?

[rüdiger]

Gregor schrieb:

Ich habe schon weiter oben gesagt, dass es mir hier nicht auf das Aussehen dieser Zeile ankommt. Was mir persönlich wichtig ist, ist die Organisation des Codes. ...das Design.

Was meinst du mit "Organisation des Codes. ...das Design."? Das es ein Keyword class gibt, in dem man alle Methoden ablegt? Das finde ich ist eine sehr eingeschränkte Sicht und entspricht ja eher der kleineren Zahl an OOProgrammiersprachen.

Warum sollte

(defclass foo () ((bar :initarg :bar :reader bar)))

(defgeneric do-sth (o))
(defmethod do-sth ((obj foo))
  (+ 100 (bar obj)))

nicht objektorientiert sein? Weil ich hier kein Schlüsselwort class benutzt habe um die Methode an die Klasse zu binden, sondern dies über eine generische Spezialisierung erledige.

Ich habe aus Deinen Äußerungen entnommen, dass Du das in keinster Weise nachvollziehen kannst.

Natürlich kann man das nicht nachvollziehen. Weil du Objektorientierung anhand von Formalien definierst. Das wäre so, als würde ich sagen "Essen ist alles was man mit einer Gabel macht" und damit ausschließen, dass jemand der "die Suppe mit einem Löffel verzehrt" oder jemand der "Stäbchen anstelle einer Gabel benutzt" isst. Wenn man dann noch den Fall findet, bei jemand eine Gabel zum Beispiel als Werkzeug benutzt, als Nahrung zu verzehren (wie zB Klassen als Namespace-Missbrauch bei Math), sollte es einem doch auffallen.

Du sagst, "OOP ist, wenn man sich an Objekten orientiert" und "Das findet alles im Kopf statt". Nach Deinen Äußerungen ist praktsich alles OOP, wenn da nur einer sagt: "Für mich ist das OOP, weil ich damit ne OO-Vorstellung verbinde.".

"man programmiert objektorientiert, wenn man sich beim programmieren an objekten orientiert" Ist doch eine Definition und das spiegelt sich auch im Code wieder. Selbst wenn man kein Keyword "class" hat.

[Zeus]

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?

[Gast]

Ich moechte, um Ruedigers Beitrag, den ich sehr gut finde, zu ergaenzen, nur ein Stichwort einwerfen, bei dem ich nicht weiss, ob es schon gefallen ist (hab mir nicht den gesamten Thread durchgelesen).

Der Ansatz, den zB CLOS bei der Objektorientierung verfolgt, bei dem sich Methoden (in LIsp auch Multimethoden genannt) nicht auf jeweils eine Klasse spezialisieren, nennt sich Multiple dispatch; im Gegensatz dazu steht das in vielen Mainstream-Sprachen vorgefundene single dispatch.

[Gregor]

rüdiger schrieb:

"man programmiert objektorientiert, wenn man sich beim programmieren an objekten orientiert" Ist doch eine Definition und das spiegelt sich auch im Code wieder. Selbst wenn man kein Keyword "class" hat.

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

"Definiere Blau!"

Definition Blau: Blau ist blau.

[Zeus]

Kennst jemand den Unterschied von objektbasierende Programmiersprachen?

[Möpschen]

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.