Es ging ja nur darum, ob C++ eine Objektorintierte Sprache ist. Wie sinnvoll ein Zwang zur Kapselung ist ist wieder eine andere Frage. Aber ohne Kapselung geht schon ein wesentlicher Grund für die Verwendung von Klassen verloren, nämlich Programmierung weniger fehleranfällig zu machen.Kaeru Gaman hat geschrieben:wozu nen priester zitieren, wenn man selber mit göttern reden kann?
das der zwang zur kapselung nicht sinnvoll ist, ist ein völlig logisches argument.
außerdem: da steht, C++ und JAVA sind keine OOP nach Kay.
PureBasic, C++, Java und die ganze Sprachenscha(r)
-
- Beiträge: 17389
- Registriert: 10.11.2004 03:22
ich denk halt dran...
wenn ich tausende von objekten mit zig startwerten versorgen will,
und für jeder wert nen einzelnen function-call brauche, is die performance beim geier.
natürlich war performance kein aspekt beim entwurf des OOP,
aber man sollte trotzdem dran denken.
wenn ich tausende von objekten mit zig startwerten versorgen will,
und für jeder wert nen einzelnen function-call brauche, is die performance beim geier.
natürlich war performance kein aspekt beim entwurf des OOP,
aber man sollte trotzdem dran denken.
Der Narr denkt er sei ein weiser Mann.
Der Weise weiß, dass er ein Narr ist.
Der Weise weiß, dass er ein Narr ist.
-
- Beiträge: 338
- Registriert: 05.09.2004 18:47
@Ligatur:
es ist für mich ziemlich offensichtlich, dass du noch nicht objektorientiert programmiert hast.
Kapselung ist sinnvoll, da wo sie einem zweck dient. Bietet eine Programmiersprache nicht die möglichkeit da zu kapseln wo es sinnvoll ist, dann ist sie keine objektorientierte programmiersprache. Alan Kay ist ein theoretiker, der es sich leisten kann prinziep vor realität zu setzen.
Ein programm verliert aber nicht an sicherheit und stabilität, wenn man dort auf kapselung verzichtet, wo sie vollkomener quatsch ist.
Sagen wir, wir haben ein objekt das ein Fenster steuern soll mit der eigenschaft, dass das Fenster auf der x-achse nur an positionen stehen darf, die ein vielfaches von 10 sind. Dann macht es sinn eine Setterfunktion dafür zu schreiben, die verhindert das die x position einen ungültigen wert annimmt, wie zb 24. Ist es aber egal, wo das fenster auf der x-achse steht dann würde eine setterfunktion so aussehen:
Was in der Funktion vollkommen identisch ist mit
Wenn du tatsächlich Kays anspruch als maß für eine Objektorientierte Sprache nimmst (wozu ich mal anmerken möchte das entgegen anderslautender Gerüchte Kay nicht der einzige Mensch auf dem Planeten ist und auch nicht der einzige Informatiker), dann ist auch die aktuellste Implemantierung von Lisp (Dylan) afaik nichtmehr objektorientiert, dann gibt es übrigens auch keine Risc-Prozessoren, weil Riscprozessoren in theoretischer reinform ebenfalls nicht praktikabel sind.
Im wissenschaftlichen umfeld gibt es viele Puristen, die dermaßen auf den theoretischen Grundlagen bestehen, dass ihre Lösungen sogar Teilweise überhauptnicht funktionsfähig sind (siehe einige akademische implementierungen von Wireless Mesh Networks, die tatsächlich nur unter simulationsbedingungen funktionieren).
Übrigens gibt auch die ISO definition von Objektorientierter Programmierung Kay nicht recht. Natürlich kannst du dich seiner Meinung anschließen und darauf bestehen, dass man uneffiziente implementierungen schreibt, aber die mehrheit derjenigen, die den begriff objektorientiert benutzt sind eben anderer Meinung.
es ist für mich ziemlich offensichtlich, dass du noch nicht objektorientiert programmiert hast.
Kapselung ist sinnvoll, da wo sie einem zweck dient. Bietet eine Programmiersprache nicht die möglichkeit da zu kapseln wo es sinnvoll ist, dann ist sie keine objektorientierte programmiersprache. Alan Kay ist ein theoretiker, der es sich leisten kann prinziep vor realität zu setzen.
Ein programm verliert aber nicht an sicherheit und stabilität, wenn man dort auf kapselung verzichtet, wo sie vollkomener quatsch ist.
Sagen wir, wir haben ein objekt das ein Fenster steuern soll mit der eigenschaft, dass das Fenster auf der x-achse nur an positionen stehen darf, die ein vielfaches von 10 sind. Dann macht es sinn eine Setterfunktion dafür zu schreiben, die verhindert das die x position einen ungültigen wert annimmt, wie zb 24. Ist es aber egal, wo das fenster auf der x-achse steht dann würde eine setterfunktion so aussehen:
Code: Alles auswählen
;Objekt-PB pseudocode
Method SetXPosition(argument_x.l)
object_x=argument_x
EndMethod
Ersteres ist viel inefizienter (brauch in der anwendung einen Funktionsaufruf) und bringt keine zusätzliche Sicherheit. Viele theoretische Konzepte lassen sich nicht realistisch in reiner Ursprungsform umsetzen.;Objekt-PB pseudocode
MyObject\object_x=position
Wenn du tatsächlich Kays anspruch als maß für eine Objektorientierte Sprache nimmst (wozu ich mal anmerken möchte das entgegen anderslautender Gerüchte Kay nicht der einzige Mensch auf dem Planeten ist und auch nicht der einzige Informatiker), dann ist auch die aktuellste Implemantierung von Lisp (Dylan) afaik nichtmehr objektorientiert, dann gibt es übrigens auch keine Risc-Prozessoren, weil Riscprozessoren in theoretischer reinform ebenfalls nicht praktikabel sind.
Im wissenschaftlichen umfeld gibt es viele Puristen, die dermaßen auf den theoretischen Grundlagen bestehen, dass ihre Lösungen sogar Teilweise überhauptnicht funktionsfähig sind (siehe einige akademische implementierungen von Wireless Mesh Networks, die tatsächlich nur unter simulationsbedingungen funktionieren).
Übrigens gibt auch die ISO definition von Objektorientierter Programmierung Kay nicht recht. Natürlich kannst du dich seiner Meinung anschließen und darauf bestehen, dass man uneffiziente implementierungen schreibt, aber die mehrheit derjenigen, die den begriff objektorientiert benutzt sind eben anderer Meinung.
-
- Beiträge: 338
- Registriert: 05.09.2004 18:47
Es gibt dutzende Definitionen der OO(P).Creature hat geschrieben:ich hab mal google bemüht und nichts gegenteiliges gefunden. ich bleibe bei meiner aussage...
Ok, Alan Kay definiert die OO und ordnet nach seiner Definition Sprachen ein und du behauptest er täuscht sich?
Nach Kay ist eine Sprache OO wenn _alles_ ein Objekt ist. Das ist in Java nicht der Fall. Dann vielleicht Actors model vs. fields. Es ist sicher noch mehr zu finden...
Jetzt erklär mir doch mal wo genau er sich täuscht?
gut, dann wiederhole ich den satz nochmal, da oben steht er.Creature hat geschrieben:Kaeru Gaman hat geschrieben: außerdem: da steht, C++ und JAVA sind keine OOP nach Kay.
wenn dieser kay behauptet, c++ und java wären nicht OOP fähig, dann ist das schlicht und ergreifend falsch.
wie sich das bei java verhält weiß ich nicht, aber mit c++ hat man die freiheit OOP zu programmieren, wenn man möchte, oder eben nicht.
und es ist auch nicht richtig, daß OOP immer dann der fall ist, wenn "alles ein objekt ist".
mit OOP kann man objekte erstellen und ineinander verkapseln, und erhält so programmcode der sehr leicht wiederverwendbar ist.
darin liegt auch der vorteil der OOP im vergleich mit herkömmlicher programmierung.
achso, nochwas: wenn du behauptest, es gäbe dutzende interpretationen von OOP, dann ist das auch falsch. das würde ja bedeuten, es sind minimum 24 interpretationen möglich, und ääähh..hust
Bildung kommt von Bildschirm und nicht von Buch, sonst hieße es ja Buchung.
-
- Beiträge: 338
- Registriert: 05.09.2004 18:47
Also nochmal. Nach Alans Definition (seine Definition; diese hat er Formuliert) soll _alles_ ein Objekt sein. Das ist bei C++ nicht der Fall. Er täuscht sich nicht, sondern definiert etwas und prüft dann, ob etwas dieser Definition entspricht. Also nochmal. Er definiert OOP und stellt fest, C++ und Java entsprechen nicht dieser (seiner) Definition.Creature hat geschrieben: wie sich das bei java verhält weiß ich nicht, aber mit c++ hat man die freiheit OOP zu programmieren, wenn man möchte, oder eben nicht.
und es ist auch nicht richtig, daß OOP immer dann der fall ist, wenn "alles ein objekt ist".
mit OOP kann man objekte erstellen und ineinander verkapseln, und erhält so programmcode der sehr leicht wiederverwendbar ist.
darin liegt auch der vorteil der OOP im vergleich mit herkömmlicher programmierung.
Nur am Rande. Die Wiederverwendbarkeit ist nicht das Ziel, sodern ein Ziel der OOP. Etwas das OO entwickelt wurde ist nicht _zwangsläufig_ oder _automatisch_ leichter wiederverwendbar als etwas das mit herkömmlicher Programmierung (wie du es nennst) entwickelt wurde.
Bonbon?Creature hat geschrieben: achso, nochwas: wenn du behauptest, es gäbe dutzende interpretationen von OOP, dann ist das auch falsch. das würde ja bedeuten, es sind minimum 24 interpretationen möglich, und ääähh..hust
Definitionen und daraus mögliche Interpretationen. Das ist wohl so! Es gibt, wie wir beide ja hier feststellen, durchaus verschiedene Definitionen. Je nachdem welche Kriterien du für die OO als wichtig erachtest. Du wirst in der Literatur unter Garantie ein Dutzend Definitionen finden können. Ich weiß nicht wie viele Bücher du zu diesem Thema gelesen hast.
der obige text ist ein zitat aus diesem link:A. Wir haben uns bewusst dafür entschieden, eine C-basierte Sprache und nicht Basic als Skriptsprache einzusetzen. C-Script verwendet die Syntax von objektorientierten Sprachen der dritten Generation wie C, C++, Java oder Javaskript.
http://www.conitec.net/german/gstudio/faq.htm#was2
du findest den text im unteren drittel des artikels.
ich stehe mit meiner auffassung offensichtlich nicht alleine da.
die entwickler vom 3D-Gamestudio sehen das auch so...
wie schon erwähnt, habe ich von deinem mao tse kay noch nichts gehört.
er mag ja ein großartiger theoretiker sein, aber etwas abseits der praxis. lies doch nochmal den beitrag von Zaphod, dann weisst du was ich meine.
im übrigen scheinst du eine neigung zur haarspalterei zuhaben, das führt meistens zu nichts

Bildung kommt von Bildschirm und nicht von Buch, sonst hieße es ja Buchung.