Was ist dran an objektorientierter Programmierung?

Das Problem an OOP ist, dass viel Neulinge meinen jeden Scheiss in Klassen verpacken zu müssen, obwohl es gar nichjt angebracht ist.

sdfsdfsd schrieb:

Das Problem an OOP ist, dass viel Neulinge meinen jeden Scheiss in Klassen verpacken zu müssen, obwohl es gar nichjt angebracht ist.

Schlimmer noch, die meisten Neulinge glauben das allein die Benutzung von Klassen ihren Code bereits objektorientiert macht.

DEvent schrieb:

jokar schrieb:

Man hat Objekte mit Datenkapselung (Information Hiding) und dann noch Vererbung und Polymorphie. Und das wars dann. Eigentlich doch garnichts besonderes, oder?

Nope, das ist eine Implementierung von OOP, in C++, C#, Java.

OOP ist das fuer was OOP steht, Object Orientierte Programmierung. Man hat nicht mit Codebloecken zu tun (wie bei der Prozeduralen Programmiering), sondern mit diskreten Objekten, die untereinander Nachrichten austauschen und aus anderen Objekten aufgebaut sein koennen.

In Python hast du z.B. keine Datenkapselung, in JS keine Vererbung, usw.

Das was da steht hat garnichts mit C++, C# oder Java zu tun. Das mit den Objekten, die untereinander Nachrichten austauschen stimmt zwar, aber ist zu wenig. Datenkapselung hast du natürlich auch in Python, wenn du objekt orientiert programmierst. Datenkapselung hat auch nichts mit Compilerprüfungen ob public oder private zu tun. Dass das hier immer falsch verstanden wird liegt glaub ich an der schlechten Übersetzung von Information Hiding bzw. Encapsulation. Es geht einfach darum, dass das Objekt eine Schnittstelle anbietet und jeder kann die verwenden, ohne wissen zu müssen was intern passiert. Das Objekt versteckt/kapselt die Information über die internen Daten/Implementierung usw.

Ich kenn mich zwar mit JS nicht aus, aber laut wikipedia hat es Vererbung, auch wenn es keine Klassen hat.
http://de.wikipedia.org/wiki/JavaScript#Vererbung_.28Die_Eigenschaft_.2Cprototype.E2.80.98.29

Vererbung (Die Eigenschaft ,prototype‘) [Bearbeiten]

Jede Funktion, d. h. jedes vom Function-Prototyp abgeleitete Objekt verfügt über eine Eigenschaft prototype. Diese übernimmt eine wichtige Aufgabe, wenn die Funktion als Konstruktor benutzt wird, um neue Objekte zu initialisieren. Die Eigenschaft prototype definiert in diesem Falle gemeinsame Eigenschaften aller Objekte, die mit dem Konstruktor erstellt werden. Man spricht von prototyp-basierter Vererbung. Auf diese Weise ermöglicht JavaScript mehrstufige Vererbung:...

volkard

<>------<>--- schrieb:

Datenkapselung hat auch nichts mit Compilerprüfungen ob public oder private zu tun. Dass das hier immer falsch verstanden wird liegt glaub ich an der schlechten Übersetzung von Information Hiding bzw. Encapsulation. Es geht einfach darum, dass das Objekt eine Schnittstelle anbietet und jeder kann die verwenden, ohne wissen zu müssen was intern passiert. Das Objekt versteckt/kapselt die Information über die internen Daten/Implementierung usw.

Und jetzt streichen wir noch das Wort "Objekt", da könnte auch Übersetzungseinheit, Modul, Funktion, Prozedur, Sub, Funktionensammlung, Struktur, Klasse, Record, Datenbanktabelle, Programm, Treiber oder irgend was anderes stehen.
So, wie Du es schreibst, scheint Datenkapselung automatisch zur Objektorientierung zu führen, das ist nicht der Fall. http://www.computerwoche.de/heftarchiv/1988/13/1154579/

volkard schrieb:

<>------<>--- schrieb:

Datenkapselung hat auch nichts mit Compilerprüfungen ob public oder private zu tun. Dass das hier immer falsch verstanden wird liegt glaub ich an der schlechten Übersetzung von Information Hiding bzw. Encapsulation. Es geht einfach darum, dass das Objekt eine Schnittstelle anbietet und jeder kann die verwenden, ohne wissen zu müssen was intern passiert. Das Objekt versteckt/kapselt die Information über die internen Daten/Implementierung usw.

Und jetzt streichen wir noch das Wort "Objekt", da könnte auch Übersetzungseinheit, Modul, Funktion, Prozedur, Sub, Funktionensammlung, Struktur, Klasse, Record, Datenbanktabelle, Programm, Treiber oder irgend was anderes stehen.
So, wie Du es schreibst, scheint Datenkapselung automatisch zur Objektorientierung zu führen, das ist nicht der Fall. http://www.computerwoche.de/heftarchiv/1988/13/1154579/

Ich hab nur erklärt, dass Datenkapselung mehr als das Vorhanden sein bzw. Unabhängig von public und private ist. Dass daraus automatisch oop wird, hab ich nie geschrieben.

DEvent

<>------<>--- schrieb:

[...] Es geht einfach darum, dass das Objekt eine Schnittstelle anbietet und jeder kann die verwenden, ohne wissen zu müssen was intern passiert. Das Objekt versteckt/kapselt die Information über die internen Daten/Implementierung usw.

Eben das hast du in Python IMHO nicht. Du kannst immer auf den internen Status des Objektes zugreifen, du kannst den Status auch aendern. Ich habe Python nur fuer ein paar Wochen benutzt, aber IMHO hat Python kein Information-Hiding. Datenkapselung ist naturlich gegeben, weil die Daten an ein Objekt gebunden sind.

JustAnotherNoob

Eben das hast du in Python IMHO nicht. Du kannst immer auf den internen Status des Objektes zugreifen, du kannst den Status auch aendern. Ich habe Python nur fuer ein paar Wochen benutzt, aber IMHO hat Python kein Information-Hiding. Datenkapselung ist naturlich gegeben, weil die Daten an ein Objekt gebunden sind.

Ich kenne die genaue Definition von Information Hiding nicht, sofern es denn eine geben sollte, deswegen möchte ich mich nicht für eine bestimmte Seite aussprechen, aber das ist definitiv mal gar nicht auf <>-----<>---s Aussage eingegangen, sondern voll daran vorbei argumentiert.
Es geht darum, das Information Hiding eine Frage des objektorientierten Konzeptes ist, dass das Objekt sie dadurch versteckt, dass man die Daten nicht kennen muss, nicht dass es unmöglich ist darauf zuzugreifen.

DEvent

JustAnotherNoob schrieb:

Eben das hast du in Python IMHO nicht. Du kannst immer auf den internen Status des Objektes zugreifen, du kannst den Status auch aendern. Ich habe Python nur fuer ein paar Wochen benutzt, aber IMHO hat Python kein Information-Hiding. Datenkapselung ist naturlich gegeben, weil die Daten an ein Objekt gebunden sind.

Ich kenne die genaue Definition von Information Hiding nicht, sofern es denn eine geben sollte, deswegen möchte ich mich nicht für eine bestimmte Seite aussprechen, aber das ist definitiv mal gar nicht auf <>-----<>---s Aussage eingegangen, sondern voll daran vorbei argumentiert.
Es geht darum, das Information Hiding eine Frage des objektorientierten Konzeptes ist, dass das Objekt sie dadurch versteckt, dass man die Daten nicht kennen muss, nicht dass es unmöglich ist darauf zuzugreifen.

Nich erkennen muss oder erkennen kann? Also ich kann die Daten erkennen, muss aber nicht? Egal was du meinst, in Python kannst du sowohl die Daten erkennen, als auch darauf zugreifen.

Schon seit anbeginn gab es "Daten" und "Code". In OOP sind die Daten und der Code eine Einheit, in einem Objekt vereint. Wenn ich also auf die Daten des Objektes zugreifen kann, dann habe ich keine "Information Hiding" mehr.

IMHO ist "Information Hiding", dass man eben nicht mehr auf die Daten des Codes zugreifen kann. In allen populaeren Sprachen wird das durch das Prizip erreicht, dass Daten eben 'private' sind und das man getter/setter hat. Python kennt sowas nicht, in Python kannst du auf die Daten direkt zugreifen und manipulieren.

Genau. In c++ geht ja auch

class test 
{
   int a;
};

...

test t;
(*(int*)&t) = 23;

also auch kein wirkliches IH.

was ich damit sagen will: in python MUSST du die information NICHT kennen, wenn es ein interface gibt. (Außerdem gibt es den underscore² präfix, aber erwachsene leute brauchen sowas nicht)

otze

Dann mach mal hier:

class base{
    virtual void foo(){}
    virtual void bar(){}
};

class test1:public base
{
    int a;
};

class test2
{
    static int a;
}

//edit auch sehr schön:

class test3
{
    class Private;
    Private* a;
};

JustAnotherNoob

@DEvent:
Was ich damit sagen will: Information Hiding und Datenkapselung sind für mich zwei gleiche Begriffe, letzteres folgt aus ersterem. Das Konzept das dahinter steckt an der Toleranz der Sprache festzumachen ist ja schmarrn.
Wenn ein Programmierer das Konzept mit (minimaler) Diziplin umsetzen kann, ist es gegeben, egal welche Sprache.