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

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

[Möpschen]

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

[Möpschen]

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

[volkard]

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.

[volkard]

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.

[Zeus]

Ich sag Gehen
Du verstehst Schlafen

Ok

[volkard]

Zeus schrieb:

Weil OOP mehr ist als dieser Satz ist.
[*]Kapselung von Methoden und Daten

nö. kapselung ist nicht notwendig. auch ungekapselt wie in perl geht beste oo programmierung.

Zeus schrieb:

[*]Polymorphie

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

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?

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