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

volkard

Zeus schrieb:

Ich sag Gehen
Du verstehst Schlafen
Ok

du hast doch gesehen, wie einfach diese definitionen zerplatzen, wie sie förmlich danach rufen, durch ein einfaches gegenbeispiel zerstört zu werden.
da hilft es auch nicht, wenn ein komitee oder professor sie verfasst hat.

das liegt aber an der buzzword-natur von "objektorientierung". es war ein erstklassiges buzzwort ein ganzes jahrzenht lang. inzwischen von den wirtschaftlern eher vergessen, versuchen wir es zurückzuerobern und mit sinn zu füllen. geht aber nicht mehr. wir müssen es als unscharfes wort behalten, zum beispiel in meiner pseudodefinition weiter oben.

volkard

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?

Gregor

volkard schrieb:

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.

volkard: Es kommt mir natürlich nicht auf die Schreibweise an. Es ist mir ziemlich egal, ob man 5.sqrt() oder sqrt(5) schreibt. Was ich für wichtig halte, ist die Organisation des Codes. Praktisch das Design. Das ist der Punkt, an dem ich mich störe. Wenn man vom Design her Objekte von den zugehörigen Methoden trennt, dann betreibt man IMHO nicht OOP. Ich habe gar kein Problem damit, wenn die Funktion swap zum swappen von Bitmaps in einem Namespace Bitmap zusammen mit anderen Bitmap-Methoden steht und darin praktisch eine globale Funktion ist. Dann nehme ich Dir ab, dass Du da OOP ohne die OOP-Sprachmittel betreibst. Die andere Organisation "alles swaps nach std" reißt aber die, von der Objektorientierung her zusammengehörenden Elemente, auseinander. Die entstehende Funktionale Gruppierung ist keine OOP mehr. Aus meiner Sicht hat OOP also ne Menge mit dem Design bzw. der Organisation des Codes zu tun. Wie Du schon sagst: Die OOP findet im Kopf statt und wenn man dann eine Gruppierung nach der Funktionalität wählt, dann zeigt das die Sicht der Dinge, die man eben so im Kopf hat. Und in dem Fall gruppiert man auch im Kopf ähnliche Funktionalitäten und oriengiert sich nicht mehr an Objekten mit ihren Eigenschaften.

Ich weiß auch nicht, warum man aus C++-Sicht so darauf fixiert ist, dass das OOP sein soll. C++ ist doch eine Multiparadigmensprache, dann kann man doch einfach sagen, dass das ein Aspekt des typischen C++-Multiparadigmenstils ist. Damit ist ja keine Wertung verbunden. Ich weiß auch nicht, warum DU jetzt gerade die "Java ist 100% OOP-Leier rausholst." Das hat hier sonst noch keiner gesagt und ich glaube, es ist jedem klar, dass das natürlich nicht so ist. Für mich erscheint so ein eingeworfenes Argument eine Variante der Chewbacca-Verteidigung zu sein: Ich sehe nicht den Zusammenhang zum diskutierten Sachverhalt.

Zeus

Hilfe mir volkard.

Stimmst du zu das Package semantisch äquvialent zu Klassen in (Java/c++) sind?

In einem Unterprogramm können mit Hilfe von local() oder my() lokale Variablen
definiert werden, die dann nur einen entsprechend eingeschränkten Gültigkeitsbereich
besitzen.

Damit ist die Fähigkeit von Perl gegeben zu kapselen, oder?

volkard

Gregor schrieb:

Was ich für wichtig halte, ist die Organisation des Codes. Praktisch das Design. Das ist der Punkt, an dem ich mich störe. Wenn man vom Design her Objekte von den zugehörigen Methoden trennt, dann betreibt man IMHO nicht OOP.

du hast nen oo-begriff, der sich an irgendwelche sachen bindet, die sofort widerlegbar wären, wenn du diese sachen auf den punkt bringen würdest. ja, man kann viel sagen, was oo nicht ist. es ist immer das, was man nicht "hübsch" findet, warumauchimmer. und der rest ist oo. oo ist demnach alles, was nicht spaghettiprogrammierung ist.

Ich habe gar kein Problem damit, wenn die Funktion swap zum swappen von Bitmaps in einem Namespace Bitmap zusammen mit anderen Bitmap-Methoden steht und darin praktisch eine globale Funktion ist. Dann nehme ich Dir ab, dass Du da OOP ohne die OOP-Sprachmittel betreibst. Die andere Organisation "alles swaps nach std" reißt aber die, von der Objektorientierung her zusammengehörenden Elemente, auseinander.

mach dich erstmal vom gedanken los, daß alles, was in std:: steht, in einer datei oder einem verzeichnis std gesammelt sein muss.
dann mach dich vom gedanken los, die schnittstelle bestünde ausschließlich aus methoden.
und finde die gleichbedeutung der folgenden codeschnipsel heraus:

class Swappable{
   virtual void swap(Swappable& b)=0;
};
class Bitmap:public Swappable{
   char* data;
   virtual void swap(Bitmap* b){
      char* tmp=data;
      data=b.data;
      b.data=tmp;
   }
};

template<typename T> swap(A& a,B& b);

class Bitmap{
   char* data;
   friend void swap(Bitmap* a,Bitmap* b){
      char* tmp=a.data;
      a.data=b.data;
      b.data=tmp;
   }
};

beide male wird irgendwoanders gesagt, daß es swap gibt und in der datei der eigenen klasse schreibt man dann, wie diese klasse es macht.

Wie Du schon sagst: Die OOP findet im Kopf statt und wenn man dann eine Gruppierung nach der Funktionalität wählt, dann zeigt das die Sicht der Dinge, die man eben so im Kopf hat. Und in dem Fall gruppiert man auch im Kopf ähnliche Funktionalitäten und oriengiert sich nicht mehr an Objekten mit ihren Eigenschaften.

kann deinen gruppierungen nicht folgen. void swap(Bitmap* a,Bitmap* b) gehört zur schnittstelle von Bitmap, denn es sagt ganz genau und eindeutig: du kannst zwei Bitmaps miteinander vertauschen.
code, den ich baue, geht sogar noch weiter, drt ist versprochen, daß ein typ, der swap anbietet, performant und vor allem exceptionfrei vertauschen kann.

Ich weiß auch nicht, warum man aus C++-Sicht so darauf fixiert ist, dass das OOP sein soll.

die aussage, es sei nicht oo, ist einfach quatsch. das ist das problem. es ist nicht einen deut mehr oo, wenn man swap in eine methode steckt oder ein Swappable-interface schafft.

Ich weiß auch nicht, warum DU jetzt gerade die "Java ist 100% OOP-Leier rausholst." Das hat hier sonst noch keiner gesagt und ich glaube, es ist jedem klar, dass das natürlich nicht so ist.

DEvent hat das eingebracht, schon ein paar seiten weiter vorher.

Bashar

volkard schrieb:

Zeus schrieb:

[*]Polymorphie

nö. self und javascript sollten... momentchen, du hast meinen link nicht verfolgt. schade.

Gibts in Self und Javascript keine Polymorphie? Du kannst doch vollkommen verschiedene Objekte, die einer bestimmten Schnittstelle entsprechen, unter dieser Schnittstelle ansprechen, oder nicht?

Zeus schrieb:

[*]Vererbung

vererbung ist schonmal gar nicht notwendig. wir sind uns hoffetlich früber einig, daß die gruppe von c-funktionen, die FILE* nimmt oder zurückgibt, ein gutes beispiel für oo sind?

Naja, das müsste man erstmal diskutieren. Ich seh das so ohne weiteres gar nicht ein, dass stdio objektorientiert sein soll.

volkard

Zeus schrieb:

Stimmst du zu das Package semantisch äquvialent zu Klassen in (Java/c++) sind?

im den hier betrachteten aspekten: jein.

sie sind übersetzungseinheiten, lager von globalen variablen und funktionen zum einen

und zum anderen namespaces und duch ein paar einfach tricks auch klassen.

In einem Unterprogramm können mit Hilfe von local() oder my() lokale Variablen definiert werden, die dann nur einen entsprechend eingeschränkten Gültigkeitsbereich besitzen.

die globalen variablen machste damit dateilokal. aber kannste auch attribute privat machen?

Damit ist die Fähigkeit von Perl gegeben zu kapselen, oder?

unter kapseln versteh ich nicht automatisch alles, was irgend jemanden von irgend was abält. lokale variablen würde ich nie gekapselt nennen. und ich denke, daß die oop-definierer mitz kapselung auch mehr meinten als globale variablen gegen andere dateien zu schützen.

nu hab ich lange nicht mehr perl gemacht. kann ich in perl4 attribute schützen?

volkard

Bashar schrieb:

Gibts in Self und Javascript keine Polymorphie? Du kannst doch vollkommen verschiedene Objekte, die einer bestimmten Schnittstelle entsprechen, unter dieser Schnittstelle ansprechen, oder nicht?

ok, ist wieder die frage, was genau gemeint war.
ich kenne keine sprache mit dem arithmetischen operator +, wo + nicht polymorh ist und doubles ganz anders addiert als integers (oder gar strings).
ich dachte jetzt an die "typische" polymorphie mit virtuellen funktionen.
kann sein, daß polymorphie notwendig ist, um eine sprache halbwegs guten gewissens objektorientierte sprache nennen zu können. kann sein, daß polymorphie notwendig ist, um eine sprache halbwegs guten gewissens sprache nennen zu können. und es gibt sogar bestimmt eine abgrenzbare sorte der polymorphie, die oo-sprachen aus den sprachen heraushebt. da muss ich aber länger drüber nachdenken.

Gregor

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

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?

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.