OOP: soll man jetzt alles in ne Klasse packen oder watt?
-
gucktmal, sogar brainfuck kann oop: http://esoteric.sange.fi/brainfuck/bf-source/prog/oobrain.b
nee echt jetz allein dass der trhead hier 13 seiten hat zeigt doch dat ihr nix könnt
-
clan der oop-ritter schrieb:
Zeus schrieb:
Zeig mir Datenkapselung in C.
// lol.h #ifndef LOL_H #define LOL_H int get(); void set(int i); #endif // lol.c #include "lol.h" static int zahl; int get() { return zahl; } void set(int i) { zahl = i; }
Da hast du deine Kapselung du "OOP-Ritter".
Hab grad zu viel intus um auf Shade einzugehen.
Aber der Code oben ist ein Witz.
Wie willst du nun mehrere Objekte erstellen ? Auch wenn du static bei zahl weglässt, kannst du nicht mehrere Objekte habe.behaupte ich nicht.
lies bitte was ich schreibe.Du hast geschrieben das es keine Kapselung in C++ gibt, und als Grund hast du deinen Textersetzer genannt #define private public
statische polymorphie ist eben etwas anderes als dynamische: da kann man nicht 1;1 die selben konzepte und regeln geltend machen.
Was du statische Polymorphie nennst, nenne ich prozedurales Programmieren. Denn diese statische Polymorphie gab es schon weitaus länger, bevor irgendjemand überhaupt auf den Begriff OOP kahm.
Nimm den Schlüsselwort namespace weg, was hast du dann? Prozeduren oder Funktionen die global verfügbar sind, die aber als Parameter ein Objekt erwarten.
Sowas habe ich schon mit Pascal und Basic programmiert.Wenn du nun Prozeduren und Funktionen hast, die statt Objekte einen Datenstrom (Stream) erwarten, nennt du es dann datenstromorientierte Programmierung ?
-
@DEvent
ob wäre das ein Problem.//foo.h struct foo; struct foo *new_foo(int bar); void delete_foo(struct foo *obj); //public accessors int get_bar(struct foo *obj); void set_bar(struct foo *obj, int i); int get_baz(struct foo *obj); //Methoden void calc_baz(struct foo *obj); //foo.c #include <stdlib.h> struct foo { int bar; int baz; int secret; }; struct foo *new_foo(int bar) { struct foo *obj = malloc(sizeof(struct foo)); obj->bar = bar; obj->secret = 100; return obj; } void delete_foo(struct foo *obj) { free(obj); } int get_bar(struct foo *obj) { return obj->bar; } void set_bar(struct foo *obj, int bar) { obj->bar = bar; } int get_baz(struct foo *obj) { return obj->baz; } void calc_baz(struct foo *obj) { obj->baz = obj->secret * obj->bar; }
Braucht kein Genie um das rauszufinden. Was daran ist nicht OO?
Btw. habe ich dir bereits aufgezeigt, dass du das C++ Accessor-System ohne #define umgehen kannst. Aber selbst mit #define wäre es ein legaler Weg, da der C++ Standard das erlaubt.
-
Aber selbst mit #define wäre es ein legaler Weg, da der C++ Standard das erlaubt.
Dann ist der C++ Standard noch schlimmer als ich dachte und ich bin froh mit C++ aufgehört zu haben
Aber verflucht noch mal ich wollte eigentlich in eine Disco....
-
rüdiger schrieb:
@DEvent
ob wäre das ein Problem.//foo.h struct foo; struct foo *new_foo(int bar); void delete_foo(struct foo *obj); //public accessors int get_bar(struct foo *obj); void set_bar(struct foo *obj, int i); int get_baz(struct foo *obj); //Methoden void calc_baz(struct foo *obj); //foo.c #include <stdlib.h> struct foo { int bar; int baz; int secret; }; struct foo *new_foo(int bar) { struct foo *obj = malloc(sizeof(struct foo)); obj->bar = bar; obj->secret = 100; return obj; } void delete_foo(struct foo *obj) { free(obj); } int get_bar(struct foo *obj) { return obj->bar; } void set_bar(struct foo *obj, int bar) { obj->bar = bar; } int get_baz(struct foo *obj) { return obj->baz; } void calc_baz(struct foo *obj) { obj->baz = obj->secret * obj->bar; }
Braucht kein Genie um das rauszufinden. Was daran ist nicht OO?
Btw. habe ich dir bereits aufgezeigt, dass du das C++ Accessor-System ohne #define umgehen kannst. Aber selbst mit #define wäre es ein legaler Weg, da der C++ Standard das erlaubt.
Doch das ist OOP. Zwar ohne die Vorteile von zB Vererbung, aber im Grunde ist es OOP. Es hat Datenkapselung, obwohl was hindert mich daran zB #include foo.c zu schreiben ?
Aber das ist ja nicht was Shader als OOP bezeichnet.
-
Hab grad zu viel intus um auf Shade einzugehen.
Aber der Code oben ist ein Witz.Ich würde dir generell empfehlen, dass du ein wenig nachdenkst, bevor du irgend etwas antwortest (selbst wenn du was intus hast), denn es war lediglich Datenkapselung gefordert.
Zwar ohne die Vorteile von zB Vererbung, [...]
Hast du überhaupt schonmal in Erwägung gezogen, dir die Argumente der anderen auch nur ansatzweise durchzulesen? Im Zuge der Diskussion wurde bereits mehrmals auf ein Dokument verwiesen, dass objektorientierte Programmierung in C genauer beschreibt und so eben auch Vererbung.
obwohl was hindert mich daran zB #include foo.c zu schreiben ?
Genau der selbe Bereich im Verstand, der dir auch bei einem #define private public ein seltsames Gefühl in der Bauchgegend verschafft.
Außerdem lässt sich sowieso eine Verständnisschwäche von OOP erkennen, wenn man auf derartig "konkrete Klassen" wie MenuDatei, MenuBearbeiten, etc.. fixiert ist.
-
DEvent schrieb:
Doch das ist OOP. Zwar ohne die Vorteile von zB Vererbung, aber im Grunde ist es OOP.
Auch das ist möglich. Aber lies dir mal das Buch "OOP with ANSI C" durch (ein Link auf die PDF wurde hier übrigens 2mal gepostet)
Es hat Datenkapselung, obwohl was hindert mich daran zB #include foo.c zu schreiben ?
Wie wir gezeigt haben, kannst du auch in anderen Programmiersprachen die Zugriffskontrolle umgehen (selbst wenn du das #define-Beispiel nicht hinnehmen willst, ich habe ein Beispiel ohne #define gezeigt, welches du ja offensichtlich überlesen willst).
Aber das ist ja nicht was Shader als OOP bezeichnet.
Weil?
Aber im Grunde ist es Sinnlos sich mit dir zu unterhalten.
-
clan der oop-ritter schrieb:
Zeus schrieb:
Zeig mir Datenkapselung in C.
// lol.h #ifndef LOL_H #define LOL_H int get(); void set(int i); #endif // lol.c #include "lol.h" static int zahl; int get() { return zahl; } void set(int i) { zahl = i; }
Da hast du deine Kapselung du "OOP-Ritter".
Sry, das ist Informations Hidding und nicht Kapselung!!!!
aqivalent mit folgend Code:
class{ public: int i; }
zu
class{ private: int i; }
aber nix OOP.
-
rüdiger schrieb:
Wie wir gezeigt haben, kannst du auch in anderen Programmiersprachen die Zugriffskontrolle umgehen (selbst wenn du das #define-Beispiel nicht hinnehmen willst, ich habe ein Beispiel ohne #define gezeigt, welches du ja offensichtlich überlesen willst).
#define private public ist afaik laut Standard verboten. Man darf keine keywords definen. Also fällt der Weg schonmal weg. Das andere was Du geschrieben hast ist natürlich genauso unportabel und undefiniert.
-
für die javaprogrammierer folgt hier ein ansatz, der wo nicht so kompliziert sein tut.
ein ahnunghaber nimmt ein problem mit OOA auf.
und ein zweiter ahnunghaber designed das programm mit OOD.
resultat sind ganz einfache anweisungen und viel UML.
dann kommen viele nichtanhnunghaber und codieren das.
die programmierer haben weder die berechtigung noch die möglichkeit,
am design entscheidendes zu ändern. ob die mit relativ wenig arbeit
das in java/c++ oder mit mehr arbeit in c/basic machen, ist egal.
selbst wenn sie ein mit UML entworfenes programm in assembler schreiben (und fast nix anderes macht der compiler am ende), bleibt es objektorientiert.
also kann man nicht an einem sprachmittel festmachen, ob das programm objektorientiert ist.OOA=objektorientierte analyse
OOD=objektorientiertes design
-
-
Jester schrieb:
#define private public ist afaik laut Standard verboten. Man darf keine keywords definen. Also fällt der Weg schonmal weg. Das andere was Du geschrieben hast ist natürlich genauso unportabel und undefiniert.
mit type-casts bekommt man aber jedes 'private' weg
volkard schrieb:
ob die mit relativ wenig arbeit
das in java/c++ oder mit mehr arbeit in c/basic machen, ist egal.
selbst wenn sie ein mit UML entworfenes programm in assembler schreiben (und fast nix anderes macht der compiler am ende), bleibt es objektorientiert.es gibt auch uml-malprogramme die erzeugen gleich quelltexte, auch in nicht-oo sprachen. da braucht's nocht nicht mal einen, der codes rein hackt...
-
net schrieb:
Jester schrieb:
#define private public ist afaik laut Standard verboten. Man darf keine keywords definen. Also fällt der Weg schonmal weg. Das andere was Du geschrieben hast ist natürlich genauso unportabel und undefiniert.
mit type-casts bekommt man aber jedes 'private' weg
Zeig mal bitte eine portable, standardkonforme Lösung um das private wegzukriegen. Ich bin gespannt. (Bitte keine Sonderfälle wie ne template-Funktion in der Klasse oder sowas).
-
Jester schrieb:
Zeig mal bitte eine portable, standardkonforme Lösung um das private wegzukriegen. Ich bin gespannt. (Bitte keine Sonderfälle wie ne template-Funktion in der Klasse oder sowas).
nö, was ganz einfaches:
// diese klasse gibt's schon class A { // alles private int a; int b; }; // diese hilfsstruct braucht man für das casting struct B { // alles public int a; int b; }; ... A a; a.b = 1234; // geht nicht, weil private ((B*)&a)->b = 1234; // geht ...
ob's standardkonform ist??? aber es sieht so aus...
-
Sorry Leute, aber
Objektorientierte Programmierung ist nicht wenn man eine nicht OOP Sprache an mich nehme und Code schreibt, der augenscheinlich die Definition von OOP erfült.
Den in der Programmierung steht die Sprache in Vordergrund.Wenn ihr sagt ich hab eine OO-Umsetztung in prozedualen Programmiersprachen (OOP-like), dann würde ich es akzeptieren, denn eine Umsetztung ist wirklich sehr leicht.
OOP bringt Konzepte mit sich, um Beschreibung zu tätigen aus der Realen Welt.
Und bei euren Lösung ist recht technisch, viele Zeiger, funktionen,....Der Vorteil ist doch die Einfachheit(ich meine damit nicht dass das Konzept einfach zu verstehen ist), wenn man so die Codebeispiele von ANIS C OOP sieht, bleibt aber nix übrig.
-
Zeus schrieb:
Denn in der Programmierung steht die Sprache in Vordergrund.
nee, das wär ja schlimm. die sprache ist nur ein werkzeug. wenn du einen teller suppe auslöffelst steht das stillen deines hungers im vordergrund und nicht der löffel
-
Zeus schrieb:
Sorry Leute, aber
Objektorientierte Programmierung ist nicht wenn man eine nicht OOP Sprache an mich nehme und Code schreibt, der augenscheinlich die Definition von OOP erfült.
Den in der Programmierung steht die Sprache in Vordergrund.Ach ja. Wie nennst du denn prozeduralen Code der in einer OOP-Sprache geschrieben ist?
Zeus schrieb:
Wenn ihr sagt ich hab eine OO-Umsetztung in prozedualen Programmiersprachen (OOP-like), dann würde ich es akzeptieren, denn eine Umsetztung ist wirklich sehr leicht.
Eine objektorientierte Umsetzung die der objektorientierten Programmierung quasi ähnlich ist, hm?
[/quote]
-
Zeus schrieb:
Den in der Programmierung steht die Sprache in Vordergrund.
bei mir ist die sprache nur ein tool. ein hilfsmittel um den code zu schreiben.
manche sachen erleichtert sie mir, andere macht sie mir schwerer.
aber die sprache ist nur dumme syntax. nicht mehr.
ich kann in Java strukturiert programmieren und in C objekt orientiert.
Wenn ihr sagt ich hab eine OO-Umsetztung in prozedualen Programmiersprachen (OOP-like), dann würde ich es akzeptieren, denn eine Umsetztung ist wirklich sehr leicht.
OOP-like. was heisst das fuer dich. es ist genau wie OOP? ja, wenn es genauso ist, dann ist es dass ja. Wenn es danach riecht schmeckt und sich so anfuehlt...?
OOP bringt Konzepte mit sich, um Beschreibung zu tätigen aus der Realen Welt.
Und bei euren Lösung ist recht technisch, viele Zeiger, funktionen,....Deine Loesung hat Klassen, Methoden, vtables,...
auch nicht wirklich viel untechnischer, oder?lediglich dass C++ deine variante besser unterstuetzt und mehr tools dafuer bietet. in Javascript saehe es umgekehrt aus. da sind deine klassen wahnsinnig kompliziert zu machen...
Der Vorteil ist doch die Einfachheit(ich meine damit nicht dass das Konzept einfach zu verstehen ist), wenn man so die Codebeispiele von ANIS C OOP sieht, bleibt aber nix übrig.
ah, also wenn es kompliziert ist, ist es nicht echt?
template metaprogamming ist also nicht template metaprogramming weil es sau kompliziert ist und lisp es wesentlich leichter anbietet?eine sprache ist ein werkzeug um dir zu helfen verschiedene konzepte zu verwenden. zB bietet dir C++ templates fuer statische polymorphie (nochmal: ich erfinde das nicht, dass ist ein teil von C++ ein grund warum C++ so maechtig ist - ich diskutiere jetzt sicher nicht darueber ob statische polymorphie auch polymorphie ist oder sonstwas. das ist ein konzept dass es schon lange gibt und C++ zB mit seinen templates unterstuetzt. das euch am bekanntesten beispiel ist sicher der operator+ der fuer zB int und double. das ist statische polymorphie. ocaml verbietet das zB und hat + fuer int+int und +. fuer double+.double - es sind einfach konzepte die es gibt. und nur weil ihr sie nicht kennt, sind sie nicht einfach schlecht. ein op+ fuer string und int mag fragwuerdig sein, aber sogar java kann diese minimale statische polymorphie, weil es manchmal einfach praktisch ist sie zu haben. C++ geht weiter und erlaubt diese polymorphie fuer mehr als nur die mathematischen operatoren.)
eine sprache bietet nun hilfmittel fuer gewisse konzepte. zB bietet C++ keine hilfe fuer Interfaces. Dennoch verwendet man manchmal welche. Aber nicht immer. Denn vieles macht man mit statischer polymorphie. zB das ganze Container Konzept der STL basiert darauf.
Aber obwohl mir C++ keine hilfe fuer interfaces anbietet, kann ich interfaces verwenden. Javascript bietet mir keinerlei hilfe fuer access control - aber ich kann es dennoch irgendwie simulieren. C++ bietet mir keinerlei hilfe fuer multimethods - aber ich kann es dennoch irgendwie simulieren. C bietet mir keinerlei hilfe fuer dynamische polymoprhie - aber ich kann es dennoch irgendwie simulieren.
und wollen wir jetzt code bewerten ob er OO ist, je nachdem wie schwer es war gewisse konzepte zu modellieren?
javascript hat keine zugriffskontrolle und in C++ und Java kann ich sie recht simpel umgehen. und der rest ist gegeben. In C kann ich uebrigens den zugriff genau wie in JS verbieten indem ich die implementierung verstecke:
struct MyClass { void* impl; }; struct MyClassImpl { int a, b; }; MyClass* make_MyClass(int a, int b) { MyClass* c=malloc(sizeof(MyClass)); MyClassImpl* impl=malloc(sizeof(MyClassImpl)); impl->a=a; impl->b=b; c->impl=impl; return c; }
und schon kann ich nicht mehr auf a und b zugreifen.
wenn jemand sagt dass man ja casten kann: MyClassImpl ist einfach nicht oeffentlich sondern liegt in einer .c datei.fertig ist die kapselung.
sinnloser aufwand - denn mir persoenlich reicht der vertrag den ich schliesse wenn ich ein objekt erstelle, nicht in den innereien rumzupfuschen.
aber bitte, hier ist access control in C
-
net schrieb:
Zeus schrieb:
Denn in der Programmierung steht die Sprache in Vordergrund.
nee, das wär ja schlimm. die sprache ist nur ein werkzeug. wenn du einen teller suppe auslöffelst steht das stillen deines hungers im vordergrund und nicht der löffel
Für eine Lösung ist die Sprache nur ein Werkzeug.
Zeus schrieb:
Sorry Leute, aber
Objektorientierte Programmierung ist nicht wenn man eine nicht OOP Sprache an mich nehme und Code schreibt, der augenscheinlich die Definition von OOP erfült.
Den in der Programmierung steht die Sprache in Vordergrund.Ach ja. Wie nennst du denn prozeduralen Code der in einer OOP-Sprache geschrieben ist?
Für mich sind das keine Äquivalenzen.
Ich versuchs mal Veranschlaulichen in dem ich sage Objektorientierte Programmierung ist ein Hülle der prozeduale Programmierung.
Vielleicht macht es dann Click
-
Shade Of Mine schrieb:
Aber obwohl mir C++ keine hilfe fuer interfaces anbietet, kann ich interfaces verwenden.
eh? Kauf dir ein Gutes C++ Buch, dass wird dir Interfaces in C++ zeigen.
Und auf dem Rest gehe ich nicht mehr ein.