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

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

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