Was kommt nach den Grundlagen?

[Sarirtanas]

Ach ne.

Nexus schrieb:

Du klammerst dich zu sehr an der OOP-Definition fest, wie sie z.B. in Java benutzt wird. Um OOP zu lernen, wie du sie verstehst, ist daher auch eine solche Sprache geeigneter. Daher auch "Aber gewisse Techniken und Design Patterns wirst du nur in C++ antreffen".

Welche Design Patterns wird man nur in C++ antreffen?

[cooky451]

double-b schrieb:

Im Prinzip bauen doch alle Windows Frameworks auf der Windows API auf,
oder?

Ja.

Nachtrag:
Der für Windows compilierte C/C++ Code baut allerdings auch auf der WinAPI auf. Deshalb läuft für Windows compilierter Code ja auch nicht auf UNIX System und umgekehrt. WinAPI ist ganz klar ein Schritt in richtung low-level bzw. C. Ich persönlich begrüße das zwar, aber im Endeffekt ist es dein Bier dich zu entscheiden. Es gibt hier keine klare Vorgehensweise. Wenn du lieber zu erst wissen möchtest wie das alles funktioniert etc. fang mit low-level an. Wenn du viel Wert auf schnelle klickibunti Fenster legst, fang mit high-level an.

Aber stelle hier bloß niemals die Frage womit man anfangen sollte, das artet schon in Religionskriege aus! (An denen ich mich natürlich gerne beteilige :D)

[Nexus]

Sarirtanas schrieb:

Welche Design Patterns wird man nur in C++ antreffen?

Ich meinte mit "nur" nicht "nirgends sonst", sondern "in C nicht".

Aber es gibt natürlich etliche C++-spezifischen Techniken und Idiome, auch wenn der Grossteil der Leute diese nicht als Design Patterns bezeichnen würde. Hier findest du eine ganze Menge davon.

[!rr!rr_.]

Nexus schrieb:

"Reine OOP" wird sowieso überschätzt, mehr Reinheit führt nicht automatisch zu besserer Qualität.

ja, das hört man öfter aus der {C++ | java | etc}-Ecke.

http://de.wikipedia.org/wiki/Der_Fuchs_und_die_Trauben

[Gregor]

Nexus schrieb:

Gregor schrieb:

Die Frage ist aber, ob die Programmiersprache die gedanklichen Konstrukte, die man bei einer objektorientierten Sichtweise hat, ebenfalls bietet oder ob sie das nicht tut. [...] C macht das nicht. In C muss man sich die Konstrukte selbst zurechtbiegen und sich dann halt sagen "Wenn da XYZ steht, dann ist das für mich eine Umsetzung von Polymorphie".

Nein, du denkst viel zu weit. Polymorphie und Vererbung sind Eigenschaften des Begriffs OOP, wie man ihn in Java oder C++ üblicherweise verwendet. Aber im Grunde genommen bedeutet "objektorientiert" nur, dass man in Objekten denkt und sein Programm entsprechend strukturiert. Das gilt für viele C-Programme, die keine Hacks benutzen. FILE* aus der Standardbibliothek ist auch ein berühmtes Beispiel.

Polymorphie gehört durchaus jenseits von bestimmten Programmiersprachen zu Objektorientierung. Was heißt denn, "in Objekten denken"? Wenn man in Objekten denkt, dann haben diese Objekte gewisse Eigenschaften und sie können gewisse Dinge ausführen. Und man denkt dann, dass diese Objekte über Nachrichten miteinander kommunizieren. Wenn ein Objekt einem anderen Objekt die Nachricht "Fahr mal vorwärts!" schickt, dann ist das Verhalten des Objekt auf diese Nachricht vom Objekt selbst und von der Situation abhängig. Ein Auto fährt anders vorwärts als ein Fahrrad. Das ist Polymorphie. Dieser Begriff und diese Denkweise hat gar nichts mit einer bestimmten Programmiersprache zu tun.

Du musst es anders sehen. Du verbiegst C derart, dass Du dort eine Art von Objekten hast und sagst dann, fahreVorwärts(a,50,30) ist praktisch nur eine andere Form, um a.fahreVorwärts(50,30) zu sagen. Dann siehst Du, dass bestimmte Konzepte auf dieser Basis schwieriger umzusetzen sind und definierst kurzerhand die Idee der Objektorientierung um. Du sagst dann, dass Dinge wie Polymorphie nur eine Eigenart bestimmter Sprachen ist, weil Du es vielleicht nicht nutzen möchtest. Aus meiner Sicht ist es aber eher so, dass Du dann in C ausschließlich eine Untermenge der Konzepte nutzt, die als Gesamtes die Objektorientierung ausmachen. Du sagst dann, die Untermenge ist OOP, also betreibst Du OOP in C. In Wirklichkeit ist die Untermenge aber nur eine Untermenge und nicht mehr.

Abgesehen davon kann es natürlich trotzdem sinnvoll sein, im Rahmen von C an Objekte zu denken. Das sehe ich ein.

Nexus schrieb:

!rr!rr_. schrieb:

C ist nicht optimal geeignet, um OOP zu erlernen, kein Zweifel. Das sind C++ und java aber auch nicht. Reine OO-Sprachen sehen ganz anders aus.

"Reine OOP" wird sowieso überschätzt, mehr Reinheit führt nicht automatisch zu besserer Qualität. Was ich an C++ so mag, ist zum Beispiel die Möglichkeit, verschiedenste Paradigmen (prozedural, objektorientiert, generisch, funktional) zu vereinen.

Ja, das sehe ich auch so. Man muss bestimmten Programmierparadigmen nicht zu 100% anhängen. Es kann durchaus angebracht sein, bestimmte Teile eines Programms anders zu programmieren als andere. Allerdings glaube ich, dass ein Anfänger erstmal eine reine Sichtweise auf die unterschiedlichen Denkweisen bekommen sollte. Das Mischen von unterschiedlichen Techniken ist etwas fortgeschrittenes und man sollte sich sehr darüber im Klaren sein, warum man das an bestimmten Stellen macht. Wenn sich ein Anfänger sagt "ach, ich werfe da jetzt mal ein paar Dinge durcheinander", dann kommt da vermutlich eher nur ganz mieser Programmierstil raus.

[double-b]

Meine Frage "Was kommt nach den Grundlagen?" hat hier wohl heftige
Diskussionen ausgelöst . Ich werde mich in Zukunft wohl mit der
Windows Programmierung, also der WinApi beschäftigen, obwohl ich mir
jetzt bewusst bin, dass diese Schnittstelle ziemlich low-level ist und
direkt keine Abstraktionsmechanismen unterstützt. Da mir die
Schnittstelle dann aber die Grundfunktionen liefert, kann ich mit
Sicherheit nach meinem Bedarf Klassen erstellen, die diese Grundfunktionen
verwalten und zusammenfassen, vielleicht für eine Fensterklasse.

[fr33g]

Ich hab mich auch mal mit der Win-API beschäftigt und mir ein paar eigene Klassen daraus gemacht, ist auf jeden Fall sehr interessant, aber auf Dauer wars iwie doch nicht meins. Is halt schon sehr umständlich, das war aber nicht mein Problem, sondern ich wollte eben mehr in Richtung C++ gehen anstatt C, genau das viel mir mit der WIN-API sehr schwer.

Lg freeG

[Nexus]

Gregor schrieb:

Aus meiner Sicht ist es aber eher so, dass Du dann in C ausschließlich eine Untermenge der Konzepte nutzt, die als Gesamtes die Objektorientierung ausmachen. Du sagst dann, die Untermenge ist OOP, also betreibst Du OOP in C. In Wirklichkeit ist die Untermenge aber nur eine Untermenge und nicht mehr.

Das heisst, wenn ich in ein Java-Programm schreibe, in dem ich keine Polymorphie implementiere, ist das nicht OOP? Muss ich sämtliche Features einsetzen, damit mein Code objektorientiert ist?

[Gregor]

Nexus schrieb:

Gregor schrieb:

Aus meiner Sicht ist es aber eher so, dass Du dann in C ausschließlich eine Untermenge der Konzepte nutzt, die als Gesamtes die Objektorientierung ausmachen. Du sagst dann, die Untermenge ist OOP, also betreibst Du OOP in C. In Wirklichkeit ist die Untermenge aber nur eine Untermenge und nicht mehr.

Das heisst, wenn ich in ein Java-Programm schreibe, in dem ich keine Polymorphie implementiere, ist das nicht OOP? Muss ich sämtliche Features einsetzen, damit mein Code objektorientiert ist?

Man muss das doch andersherum sehen. Du hast eine objektorientierte Sichtweise auf irgendetwas. Und jetzt willst Du das in einer Programmiersprache umsetzen. Dazu sind vielleicht bestimmte Sprachmittel vorhanden oder eben nicht. Zumindest musst Du bei der Umsetzung meistens gewisse Kompromisse eingehen, die Sprachabhängig sind. Und wenn man derart vorgeht, dann sieht man, dass man in bestimmten Sprachen weniger Kompromisse eingehen muss und in anderen mehr. Und für bestimmten Sprachen muss man seine gedankliche Modellierung des Sachverhalts stark umbauen, weil man Konzepte genutzt hat, die in der Sprache nur schwer zu realisieren sind.

Also wenn jemand Java programmiert und dabei prinzipiell auf Polymorphie verzichtet, dann würde ich schon sagen, dass er wohl nicht objektorientiert programmiert. Das heißt aber nicht, dass man überall krampfhaft jedes Konzept der Objektorientierung einbringen muss, nur weil die Sprache es bietet. Wenn das objektorientierte Modell, das man von einem Sachverhalt im Kopf hat, keine Polymorphie benötigt, dann braucht man dieses Konzept auch nicht bei der Umsetzung nutzen. Es ergibt sich halt einfach nicht. Allerdings reden wir jetzt von irgendwelchen Spezialfällen, was das Anwendungsgebiet betrifft. Im Allgemeinen gehört Polymorphie zur Objektorientierung dazu.

[volkard]

Gregor schrieb:

Im Allgemeinen gehört Polymorphie zur Objektorientierung dazu.

Naja, je nach Anwendung halt. Wobei man in C++ wegen der Template-Container und -Algorithmen dort schonmal keine Polymorphie (diese Art) benutzt. Und die Daten in der relationalen Datenbank auch nicht. Meistens, um ImageButton von Button erbend zu implemetieren oder sowas. Andere Sprachen rufen viel stärker nach Polymorphie. In C++ komme ich über weiten Strecken ohne aus. In Java ist es schwer feststellbar, weil man in Java nur objektorientiert programmieren kann, sagt Sun.

[Nexus]

Gregor schrieb:

Und wenn man derart vorgeht, dann sieht man, dass man in bestimmten Sprachen weniger Kompromisse eingehen muss und in anderen mehr. Und für bestimmten Sprachen muss man seine gedankliche Modellierung des Sachverhalts stark umbauen, weil man Konzepte genutzt hat, die in der Sprache nur schwer zu realisieren sind.

Hier bin ich völlig deiner Meinung. Ich würde ja auch nicht C wählen, wenn ich ein spezifisches OOP-Problem zu lösen hätte (spezifisch im Sinne von "wie auf Java o.Ä. zugeschnitten"). Aber ich habe auch nicht behauptet, dass dies sinnvoll wäre, sondern nur, dass man in C grundsätzlich objektorientiert programmieren kann (ohne dabei die ganze OOP-Palette gewisser Programmiersprachen auszunutzen). Und es gibt natürlich Sprachen, die einem besser bei der Umsetzung von OOP helfen als C.

Aber ich fürchte, unsere Vorstellungen liegen hier zu weit auseinander...

[!rr!rr_.]

also ich sehe ehrlich gesagt nicht, wie man in C objektorientiert programmieren können sollte:

Datenkapselung: nein (mit Zeigern kommt man an alles heran, auch wenn die Zieladresse private_internal_state heißt)

late-binding: nein

message passing: jein

Überhaupt die Grundidee vom Objekt als "Computer im Computer" mit eigenem kleinen Speicherbereich und einem kleinen Befehlsvorrat in Form der Methoden, auf die das Objekt reagiert, finde ich in C nicht.

Man kann bestimmte OO-Features in C simulieren, ja.

[Nexus]

!rr!rr_. schrieb:

Datenkapselung: nein (mit Zeigern kommt man an alles heran, auch wenn die Zieladresse private_internal_state heißt)

1. geht es bei der Kapselung u.A. darum, den Programmierer vor Fehlern zu schützen, und nicht die Daten geheim zu halten.
2. kannst du in C einen Zeiger auf unvollständige Typen in einer Struktur deklarieren.

[!rr!rr_.]

Nexus schrieb:

geht es bei der Kapselung u.A. darum, den Programmierer vor Fehlern zu schützen, und nicht die Daten geheim zu halten.

spätestens, wenn verschiedene Benutzer ihre eigenen Objekte erzeugen und untereinander kommunizieren lassen können, geht es auch um Geheimhaltung.

Nexus schrieb:

2. kannst du in C einen Zeiger auf unvollständige Typen in einer Struktur deklarieren.

und das ist dann Datenkapselung? Also unter Datenkapselung, soweit es Objektorientierung anbetrifft, verstehe ich im einfachsten Fall, daß man instanzvariablen vor äußerem Zugriff schützen kann, indem man einfach keine Accessors implementiert.

[Nexus]

Du glaubst, Kapselung müsse den Code vor böswilligen Angreifern schützen, oder argumentierst zumindest aus dieser Perspektive. Tatsächlich relevant ist aber die Abstraktion und der Schutz gegen unabsichtliche Zugriffe. Und diese Mechanismen sind in C sehr wohl umsetzbar.

Aber ich wiederhole mich nur...

[Dravere]

Ich würde den Schutz sogar völlig weglassen bei der Definition. Es geht nur darum Daten zu kapseln und mit Methoden zu versehen. Man kann dann auch in der Dokumentation darauf hinweisen, dass man nicht auf die Attribute zugreifen darf. Sicher ist das nicht gleich praktisch wie in einer Sprache, welche diesen Zugriff gleich zur Kompilierzeit schützt.
Aber man sehe sich zum Beispiel Python an. Da hast du grundsätzlich das ganze objektorientierte Konzept drin. Vererbung, Polymorphie, Datenkapselung, usw. nur bietet die Sprache keinerlei Schutz vor dem Zugriff. Deswegen zu behaupten, dass Python kein OOP kann, halte ich für ein wenig lächerlich

Grüssli

[!rr!rr_.]

Dravere schrieb:

Ich würde den Schutz sogar völlig weglassen bei der Definition. Es geht nur darum Daten zu kapseln und mit Methoden zu versehen.

OO als "namespace feature"

Dravere schrieb:

Aber man sehe sich zum Beispiel Python an. Da hast du grundsätzlich das ganze objektorientierte Konzept drin.

nein, hast du nicht. Das hast du hier

http://de.wikipedia.org/wiki/Smalltalk-80_(Programmiersprache)

und hier

http://de.wikipedia.org/wiki/Self_(Programmiersprache)

[Shade Of Mine]

!rr!rr_. schrieb:

Datenkapselung: nein (mit Zeigern kommt man an alles heran, auch wenn die Zieladresse private_internal_state heißt)

selbes Problem hast du in c++ mit einem #define private public
Oder javascript, php4, ...

private ist ein feature das nett ist, aber nicht essentiell ist. Wichtig ist die Kapselung: bedenke man soll sich gegen Murphy und nicht gegen machiavelli schützen. Und da reicht ein simples Konzept wie zB eine forward deklaration der Struktur, etc.

late-binding: nein

funktionszeiger.

COM ist zB eine OO API die auch Late Bindung unterstützt.

message passing: jein

message passing ist nichts anders als ein funktionsaufruf.

Überhaupt die Grundidee vom Objekt als "Computer im Computer" mit eigenem kleinen Speicherbereich und einem kleinen Befehlsvorrat in Form der Methoden, auf die das Objekt reagiert, finde ich in C nicht.

FILE* hat zB fseek, fopen, fclose, ftell,...
Und es funktioniert mit allen möglichen Sachen Der FILE* muss ja kein physikalisches File sein - kann ja zB auch im RAM liegen, etc.

Das ist halt diese Java-Einstellung Da reduziert man OO schnell auf Sprachfeatures. Aber OOP ist eine Denkweise. Und die hat nichts mit Sprachen zu tun, denn Sprachen sind nur Tools die einem helfen das gedachte für den Computer verständlich zu machen. Es gibt Tools die es erleichtern und Tools die es erschweren. Aber deshalb haben wir Turing Complete Sprachen - damit wir alles machen können..

[Gregor]

Shade Of Mine schrieb:

Das ist halt diese Java-Einstellung Da reduziert man OO schnell auf Sprachfeatures. Aber OOP ist eine Denkweise. Und die hat nichts mit Sprachen zu tun, denn Sprachen sind nur Tools die einem helfen das gedachte für den Computer verständlich zu machen. Es gibt Tools die es erleichtern und Tools die es erschweren. Aber deshalb haben wir Turing Complete Sprachen - damit wir alles machen können..

Es ist sinnvoll, Sprachen zu nutzen, in denen man das Gedachte gut ausdruecken kann. Das ist nicht nur bei Programmiersprachen so, sondern ueberall. Deshalb gibt es Fachsprachen, deshalb gibt es Formalisierungen.

C zu nutzen, wenn man objektorientierte Modellierungen umsetzen moechte, ist so, als ob man eine mathematische Formel in Alltagssprache aufschreibt. Es geht, aber es ist nicht das Mittel der Wahl, da es zusaetzliche Barrieren schafft.

[Nexus]

Gregor schrieb:

C zu nutzen, wenn man objektorientierte Modellierungen umsetzen moechte, [...] ist nicht das Mittel der Wahl, da es zusaetzliche Barrieren schafft.

Darum gehts doch nicht. Wie ich bereits geschrieben habe, würde ich für so eine Aufgabenstellung auch nicht C wählen.

Viel wichtiger ist: Wenn man C benutzt, kann man auf gewisse OOP-Konzepte zurückgreifen. Unabhängig davon, wie viel besser die Konzepte in anderen Programmiersprachen umgesetzt sind.