Was kommt nach den Grundlagen?

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

[!rr!rr_.]

Shade Of Mine schrieb:

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.

wie gesagt: ja, wenn man unter "Objektwelt" nach einer gängigen Auffassung eine Sammlung von name spaces mit Funktionszeigern versteht.

In einer dynamischen, verteilten Objektwelt, in der verschiedene Benutzer ihre eigenen Objekte erzeugen können und miteinander kommunizieren lassen können, ist Zugriffsschutz aber unabdingbar.

Shade Of Mine schrieb:

message passing ist nichts anders als ein funktionsaufruf.

nein: message passing liegt eine Abstraktionsebene höher.

message passing kann in der VM als ein bisschen pointer-chasing (Klassenzeiger usw) + Funktionsaufruf implementiert sein.

Shade Of Mine schrieb:

Das ist halt diese Java-Einstellung Da reduziert man OO schnell auf Sprachfeatures.

strongtalk ist das, was java hätte sein können.

Shade Of Mine schrieb:

Aber OOP ist eine Denkweise.

warum heißt es dann nicht OOT ?

Shade Of Mine schrieb:

Und die hat nichts mit Sprachen zu tun,

das hängt davon ab, welche Sprache(n) du meinst

[Shade Of Mine]

Gregor schrieb:

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.

Keine Frage. Das habe ich ja auch gesagt: einige Tools helfen mir mehr als andere. Natürlich nehme ich das beste Tool für den Job. Wenn aber C das beste Tool ist (zB weil es keine Java VM für die Zielplattform gibt) dann sollte ich dennoch nicht komplett auf OOP verzichten nur weil ich C habe. Guter C Code ist nämlich auch OO wie man zB an der C Library sieht.

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.

Ich denke du übertreibst etwas. Aber klar, komfortabler ist es in anderen Sprachen. Aber bei weitem nicht so komplett unmöglich. Man macht die Sachen halt etwas anders. Das ist eine ziemliche Umstellung, aber um ehrlich zu sein hatte ich da bisher wenig Probleme.

Man modelliert halt anders. Es ist klar dass man nicht 1:1 das Java Design übernehmen kann - und genau das sehe ich als Problem hier. Denn C OO-Code sieht anders aus als Java OO-Code. Und zwar komplett anders.

Die WinAPI ist zB eine Objekt Orientierte API in C. Die Handles sind gekapselt und die Callback ermöglichen das neudefinieren von verhalten (sprich was in Java Ableitung wäre).

Statt

Window w = new Window() {
   public void paint() {
      bar();
   }
};
w.show();

schreibt man in C eben:

WINDOW w = CreateWindow(...);
RegisterPaintCallback(w, paint);
ShowWindow(w);

void paint(WINDOW w) {
   bar();
}

die Implementierung ist natürlich viel netter in Java. Keine Frage. Spart Zeit und nerven. Aber es ist nicht so als es nicht gehen würde oder keinen Sinn machen würde. Es ist nur anders.

COM, WinAPI, das Filehandling der Standard Lib,...
es gibt viele Beispiele. Nur es ist halt nicht aus wie Java OOP deshalb wird es leicht abgewertet. Und ja, es ist nicht komfortabel - aber C ist generell nicht komfortabel.

[Shade Of Mine]

!rr!rr_. schrieb:

In einer dynamischen, verteilten Objektwelt, in der verschiedene Benutzer ihre eigenen Objekte erzeugen können und miteinander kommunizieren lassen können, ist Zugriffsschutz aber unabdingbar.

JavaScript, PHP4, C++, Java,... überall kann ich diese Schutzmechanismen umgehen. Können also nicht essentiell sein.

nein: message passing liegt eine Abstraktionsebene höher.

Message Passing ist Function Calling.
Aber selbst wenn nicht:
Sprachen wie C++, Java, Python,... haben nur function calls. Ergo kann es nicht essentuell sein.

Shade Of Mine schrieb:

Aber OOP ist eine Denkweise.

warum heißt es dann nicht OOT ?

Namen sind Schall und Rauch. Aber bist du echt der Meinung dass OOP keine Denkweise ist um Probleme zu lösen? Ich meine OOP ist ja nichtmal die einzige Denkweise die wir kennen. Es gibt viele andere und sogar innerhalb der OOP gibt es massig unterschiede was die Features der OOP betrifft.

das hängt davon ab, welche Sprache(n) du meinst

Nein. Ich programme in jeder Sprache OO wenn es sein muss. Die Sprache ist nur ein Tool dich auszudrücken. OOP ist nicht immer die beste Lösung. Manche probleme sind mit OOP ja nichtmal lösbar. Da modelliert man ganz komisch herum bis es schief wirkt.

OOP ist eine nette Denkweise Probleme zu lösen. Aber bei weitem nicht die einzige.

[!rr!rr_.]

Shade Of Mine schrieb:

JavaScript, PHP4, C++, Java,... überall kann ich diese Schutzmechanismen umgehen. Können also nicht essentiell sein.

englisch, französisch, spanisch, nirgendwo kann man das Wort "Wasserhahn" finden, also sind Wasserhähne unwichtig. - ?

Shade Of Mine schrieb:

Message Passing ist Function Calling. Aber selbst wenn nicht:

ja ? ... /* die Spannung steigt ins Unerträgliche */

Shade Of Mine schrieb:

Sprachen wie C++, Java, Python,... haben nur function calls. Ergo kann es nicht essentuell sein.

... schade. Der Satzteil vor dem Doppelpunkt hatte Potential.

Sei's drum. Sprachen wie C++, java, python sind keine reinen OO-Sprachen im ursprünglichen Sinne des Wortes.

Shade Of Mine schrieb:

Namen sind Schall und Rauch. Aber bist du echt der Meinung dass OOP keine Denkweise ist um Probleme zu lösen?

OOP ist eine Programmiermethodik. Daß man dabei eher in Klassen/Objekt-Begriffen denkt als in Listen oder in Prozeduren, ist wohl klar.

Shade Of Mine schrieb:

Manche probleme sind mit OOP ja nichtmal lösbar. Da modelliert man ganz komisch herum bis es schief wirkt.

ja, wenn innere Zustände keine Rolle spielen und keine abstraktionsfähigen Objekte vorkommen, etwa bei der Auswertung mathematischer Formeln, da tut es auch Funktional.

besseres Beispiel?

[Mal nachgehakt]

!rr!rr_. schrieb:

Sei's drum. Sprachen wie C++, java, python sind keine reinen OO-Sprachen im ursprünglichen Sinne des Wortes.

Was verstehst du an objektorientiert nicht? Orientierung ist keine reine Lehre, sondern eine Hinwendung, Unterstützung, Ausrichtung.

[Shade Of Mine]

!rr!rr_. schrieb:

Shade Of Mine schrieb:

JavaScript, PHP4, C++, Java,... überall kann ich diese Schutzmechanismen umgehen. Können also nicht essentiell sein.

englisch, französisch, spanisch, nirgendwo kann man das Wort "Wasserhahn" finden, also sind Wasserhähne unwichtig. - ?

Das macht absolut keinen Sinn was du da sagst.

Du behauptest ohne der moeglichkeit Daten zu schuetzen kann man keine OOP haben. Das kontere ich, indem ich dir Beispiele zeige, dass man fast nirgendwo Daten wirklich schuetzen kann. Dass dieser Schutz auch irrelevant ist, da es um Information Hiding geht um Kapselung nicht darum physikalischen Zugriff zu verbieten.

Weil es irrlevant ist ob eine Tuer zu betoniert ist oder nur zu ist um das Konzept eines abgeschlossenen Zimmers zu erreichen.

Sei's drum. Sprachen wie C++, java, python sind keine reinen OO-Sprachen im ursprünglichen Sinne des Wortes.

dh OOP ist mit C++, Java, Python, etc. nicht moeglich?

Denn genau das sagst du damit aus. Du kritisierst dass C kein "message passing" hat, aber keine Mainstream Sprache hat es. Also: wie wichtig ist es wirklich?

Kleiner Tipp: Message Passing ist nur ein Function Call. Denn Message Passing ist auch nur ein Konzept und function calling ist eine implementierung davon.

OOP ist eine Programmiermethodik. Daß man dabei eher in Klassen/Objekt-Begriffen denkt als in Listen oder in Prozeduren, ist wohl klar.

Klassen? Ganz boeses Wort hier. Klassen haben nichts mit OOP zu tun.

Aber worauf willst du hinaus? Mir nur widersprechen? Das ist langweilig...
Denn du argumentierst gerade, dass C genauso wie C++, Java, Python, C#,... ist. Also du argumentiert dafuer, dass OOP in C moeglich ist. Ist das wirklich dass was du willst??

[!rr!rr_.]

Shade Of Mine schrieb:

Weil es irrlevant ist ob eine Tuer zu betoniert ist oder nur zu ist um das Konzept eines abgeschlossenen Zimmers zu erreichen.

spätestens wenn das Bier alle ist, ist es schon ein Unterschied, ob die Tür nur geschlossen oder zubetoniert ist.

Shade Of Mine schrieb:

Denn genau das sagst du damit aus. Du kritisierst dass C kein "message passing" hat, aber keine Mainstream Sprache hat es.

ja, aber manche hätten es gern.

[Shade Of Mine]

!rr!rr_. schrieb:

spätestens wenn das Bier alle ist, ist es schon ein Unterschied, ob die Tür nur geschlossen oder zubetoniert ist.

Wenn darin aber kein Bier sondern Diamanten liegen ist es wieder egal Denn beides ist knackbar. Die Frage ist nur wie gross ist der Aufwand.

Deshalb ist information hiding ja nicht an schutzmechanismen geknuepft. Denn es macht absolut keinen Sinn. Jeder Mechanismus ist knackbar.

ja, aber manche hätten es gern.

Nur die die nicht wissen dass es keinen unterschied gibt