Was ist OOP und wo liegt der Unterschied zu anderen Vorhgehensweisen?

[</Life>]

Re: Wie Programmieren lernen?

Es gibt drei grosse Klassen von Programmiersprachen:
Imperative, objektorientierte und funktionale.
C, Pascal, etc gehören zu den imperativen, Java und Smalltalk zu den objektorientierten. Eine funktionale Sprache wäre z.B. Hascal... mit dem Ansatz habe ich mich aber noch nie beschäftigt.

Was OOP angeht:
OOP ist ja eine ganz nette Sache, aber nur, solange man es in Maßen und nicht in Massen anwendet... Wenn man einen komplexen Datentyp hat und dann dazu Methoden, die diesen Datentyp manipulieren können ist das eine gute Sache. Wenn man hingegen aus OOP eine Religion macht, wird es ranzig... Beispiel Java: true als einzige Instanz der Klasse TRUE und false als einzige Instanz der Klasse FALSE... Das ist doch dann nur noch zum Kotzen und hat mit vernünftigem Programmieren nichts zu tun... Davon abgesehen arbeiten Prozessoren nunmal imperativ und nicht objektorientiert oder funktional.

 

[marcelcedric]

Re: Wie Programmieren lernen?

Es gibt drei grosse Klassen von Programmiersprachen:
Imperative, objektorientierte und funktionale.
C, Pascal, etc gehören zu den imperativen, Java und Smalltalk zu den objektorientierten. Eine funktionale Sprache wäre z.B. Hascal... mit dem Ansatz habe ich mich aber noch nie beschäftigt.

Was OOP angeht:
OOP ist ja eine ganz nette Sache, aber nur, solange man es in Maßen und nicht in Massen anwendet... Wenn man einen komplexen Datentyp hat und dann dazu Methoden, die diesen Datentyp manipulieren können ist das eine gute Sache. Wenn man hingegen aus OOP eine Religion macht, wird es ranzig... Beispiel Java: true als einzige Instanz der Klasse TRUE und false als einzige Instanz der Klasse FALSE... Das ist doch dann nur noch zum Kotzen und hat mit vernünftigem Programmieren nichts zu tun... Davon abgesehen arbeiten Prozessoren nunmal imperativ und nicht objektorientiert oder funktional.

Da spricht unser Simon aus Erfahrung. =)
Danke fuer die Erklaerung.

mfg

 

[Morgoth]

Re: Wie Programmieren lernen?

Was OOP angeht:
OOP ist ja eine ganz nette Sache, aber nur, solange man es in Maßen und nicht in Massen anwendet... Wenn man einen komplexen Datentyp hat und dann dazu Methoden, die diesen Datentyp manipulieren können ist das eine gute Sache. Wenn man hingegen aus OOP eine Religion macht, wird es ranzig...

Da muss ich ein wenig widersprechen. Wenn schon OOP, dann richtig und konsequent. Dann ist alles ein Objekt, ob eine simple Zahl, ein String (der wieder aus mehreren Objekten der Klasse "Zeichen" besteht) oder selbst Operatoren (Objekte, die andere Objekte manipulieren). Wenn das richtig durchgezogen wird, ist es ein tolles Konzept.
Den wir Menschen denken auch so: ich gebe das Objekt "kaputtes Auto" an das Operator-Objekt "Werkstatt", das mir das Auto repariert. Wie das Operator-Objekt das macht ist mir Rille, ob per Handauflegen oder Werkzeug, wichtig ist nur, das es mein Objekt wieder in einen funktionstüchtigen Zustand versetzt.
Diese Kapselung von Vorgängen ist es, die OOP so interessant macht. Eine Mischung aus beiden Welten, imperativ oder objektorientiert, führt unweigerlich zum Chaos und schlechtem Code.

Davon abgesehen arbeiten Prozessoren nunmal imperativ und nicht objektorientiert oder funktional.

Dafür hat das Objekt "Compiler" zu sorgen, der das Objekt "Code" so manipuliert, das dem Objekt "Prozessor" dann die richtigen Häppchen serviert werden.

Sicher, ein Prozessor arbeitet so. Aber wir Menschen nicht. Wir arbeiten objektorientiert, und der Compiler/Linker bildet dann die Schnittstelle zwischen den beiden Welten (die übrigens auch wieder Objekte sind, aber das nur am Rande ).

Gruß
Morgoth

 

[</Life>]

Re: Wie Programmieren lernen?

Da muss ich ein wenig widersprechen. Wenn schon OOP, dann richtig und konsequent.

Das ist ein vollständiger Widerspruch und zudem noch ein unüberlegter (Begründung steht oben).
_____

Dann ist alles ein Objekt, ob eine simple Zahl, ein String (der wieder aus mehreren Objekten der Klasse "Zeichen" besteht) oder selbst Operatoren (Objekte, die andere Objekte manipulieren).

Für die ganz kleinen Einheiten ist es einfach nur Blödsinn, sie mit Klassenelementen zu überladen. Wenn du das WIRKLICH so konsequent durchführst wie du es sagst kannst du gar nicht erst anfangen, weil dir die einfachsten Elemente fehlen. Du kannst nicht das imperative "a-b" verwenden, sondern musst stattdessen "a.substract(b)" benutzen. Dafür musst du aber erstmal a und b initialisieren... Statt 42-18 hiesse es also: new ((new Integer(42)).substract(new Integer(18))). DAS nennst du dann ein tolles Konzept?
_____

Den wir Menschen denken auch so: ich gebe das Objekt "kaputtes Auto" an das Operator-Objekt "Werkstatt", das mir das Auto repariert. Wie das Operator-Objekt das macht ist mir Rille, ob per Handauflegen oder Werkzeug, wichtig ist nur, das es mein Objekt wieder in einen funktionstüchtigen Zustand versetzt.

Jetzt scherst du alle Menschen über deinen Kamm. Ich denke vielmehr:
Mein Auto ist kaputt.
Dann bringe ich es in die Werkstatt.
Dann lasse ich es reparieren.
Dann bezahle ich.
Dann fahre ich mit dem Auto wieder nach Hause.
Ein viel einfacheres Konzept als deine komischen Objekte, die zwar sagen, WAS passiert, aber nicht WIE es gemacht wird. Davon ist das Modell der Werkstatt als Operator unbrauchbar. Du wirst kaum heiles_auto x = kaputtes_auto y benutzen sondern auto x.repariere(werkstatt heinze) oder werkstatt heinze.repariere(auto x), womit die Werkstatt nur wieder ein anderes Objekt wäre. Davon abgesehen ist ein Operator eine Funktion und kein Objekt: Er wird mit zwei Parametern aufgerufen und hat keinerlei Eigenschaften oder Methoden.
_____

Diese Kapselung von Vorgängen ist es, die OOP so interessant macht.

Ich habe ja auch nicht gesagt, dass OOP schlecht ist, ich sagte nur, dass es nicht der Weisheit letzter Schluss ist.
_____

Eine Mischung aus beiden Welten, imperativ oder objektorientiert, führt unweigerlich zum Chaos und schlechtem Code.

Das ist nicht nur eine unbegründete Unterstellung, es ist schlicht und einfach eine Lüge. Jeder Mensch definiert "schlechten Code" anders und jeder hat seinen eigenen Stil, Code zu schreiben. Wer seinen eigenen als Optimum hinstellt und alle anderen als minderwertig und schlecht, der ist schlicht und einfach blind und dumm.
Davon abgesehen: Erklär mir mal bitte Strukturen wie while oder if rein objektorientiert. Es sind IMPERATIVE Elemente, die in einer streng objektorientierten Welt wie du sie dir wünschst nichts zu tun haben.
Und dann programmier mal objektorientiert, ohne die imperative Aufreihung von Befehlen zu benutzen. Mal schauen, ob es dir gelingt.
_____

Dafür hat das Objekt "Compiler" zu sorgen, der das Objekt "Code" so manipuliert, das dem Objekt "Prozessor" dann die richtigen Häppchen serviert werden.

Was das schon wieder für ein hinkender Vergleich sein soll ist mir schleierhaft. Nur weil es "Objekt-Orientiert" HEISST ist es nicht auf reale Objekte bezogen. Das Beispiel mit den Fahrzeugen, von denen dann Autos und Fahrräder abgeleitet werden mag ja ganz nett sein, wir haben es hier aber IMMER mit Daten zu tun. Daten sind etwas Abstraktes, wohingegen sowohl der Compiler als auch der Prozessor streng imperativ vorgehen.

 

[7H3 N4C3R]

Re: Wie Programmieren lernen?

Jetzt scherst du alle Menschen über deinen Kamm. Ich denke vielmehr:
Mein Auto ist kaputt.
Dann bringe ich es in die Werkstatt.
Dann lasse ich es reparieren.
Dann bezahle ich.
Dann fahre ich mit dem Auto wieder nach Hause.
Ein viel einfacheres Konzept als deine komischen Objekte, die zwar sagen, WAS passiert, aber nicht WIE es gemacht wird. Davon ist das Modell der Werkstatt als Operator unbrauchbar. Du wirst kaum heiles_auto x = kaputtes_auto y benutzen sondern auto x.repariere(werkstatt heinze) oder werkstatt heinze.repariere(auto x), womit die Werkstatt nur wieder ein anderes Objekt wäre. Davon abgesehen ist ein Operator eine Funktion und kein Objekt: Er wird mit zwei Parametern aufgerufen und hat keinerlei Eigenschaften oder Methoden.

Naja, jetzt muss ich Dir aber auch mal unterstellen, dass Du von objektorientierter Programmierung nicht so viel verstehst. Deine Vorgehensweise entspricht sehr stark der strukturierten Programmierung. Wenn Dich Objektorientierung interessiert, solltest Du mal dieses Buch hier lesen - das ist eines der Besten, die ich kenne.
http://www.amazon.de/exec/obidos/ASIN/3827318629/302-2387042-6499238

Zu dem Beispiel da - Du orientierst Dich viel zu stark an der C++-Terminologie Und - um es auf den Punkt zu bringen - in einem objektorientierten System wissen verarbeitenden Objekt meist nicht, WAS sie da eigentlich vor sich haben, sondern nur WIE sie es aufrufen. Das Verhalten von Objekten und ihr Zusammenspiel ist das A&O bei objektorientiertem Design.


(und nur als Anmerkung : Ein C++-Operator ist entweder eine Funktion oder eine Methode und muss keine zwei Parameter haben. Der ()-Operator bei Klassen ist z.B. frei definierbar)

 

[</Life>]

Re: Wie Programmieren lernen?

Naja, jetzt muss ich Dir aber auch mal unterstellen, dass Du von objektorientierter Programmierung nicht so viel verstehst. Deine Vorgehensweise entspricht sehr stark der strukturierten Programmierung.

Was sind Klassen? Nichts anderes als structs, die ausserdem auch noch Methoden enthalten können, um dieses struct zu manipulieren.
Man soll seine DATEN in geeigneten Klassen speichern, nicht das gesamte Programm.

Wenn du das als OOP falsch verstehen betrachtest - bitte, dann bin ich sogar stolz darauf OOP nicht richtig verstanden zu haben. Aber wie hat Morgoth das so schön erklärt: Bei OOP muss man nicht verstehen, wie es funktioniert, Hauptsache ist man kann es benutzen.

 

[Green Mamba]

Re: Wie Programmieren lernen?

Man soll seine DATEN in geeigneten Klassen speichern, nicht das gesamte Programm.

naja, das ist eben der vorteil der objektorientierung, man speicher daten und die zugehörigen operationen in klassen ab. im prinzip habt ihr ja beide zum großen teil recht, ihr redet nur irgendwie aneinander vorbei.
natürlich arbeitet der prozessor prozedural, allerdings ist der ja noch einige abstraktionsschichten weit wech, daher kann man so kaum argumentieren. das was ausm compiler raus kommt is ja imperativ.

man kann auch nicht sagen dass das eine besser als das andere ist. oop ist stark im kommen, und das nicht weils irgendwie performanter ist, was nicht der fall sein muss, sondern weil es eine weitere abstraktions-schicht darstellt, und es dem entwickler ermöglicht wesentlich besser verständliche strukturen zu erstellen, sonst nix.
alles was mit oop möglich ist, ist mit z.b. c auch möglich, nur mit mehr aufwand.
aber auch darüber kann man sich streiten, ich kenne programmierer, die zaubern die fettesten programme in plain c, allerdings steigt da außer ihnen selbst (wenn überhaupt) nach 2 wochen kaum einer mehr so richtig durch ohne so richtig viel zeit zu investieren.
oop hat auch die uml klassendiagramme hervorgebracht. das darf man nicht außer acht lassen. und ich will kein projekt mehr ohne planen.

 

[7H3 N4C3R]

Re: Wie Programmieren lernen?

@</Life>:
Nicht ganz, unter C++ sind structs Klassen, in denen alles public ist. Unter C++ (nicht C wohlgemerkt) kannst Du einem struct mal eben Methoden oder einen Konstruktor verpassen.

Okay, ich glaube, der 'Herr in Grün' hat recht, wir reden schon etwas aneinander vorbei. Alsoooo, mein Punkt ist 'nur'...echte Objektorientierung beginnt für mich mit dem Einsatz von Polymorphie. Nicht umsonst bezeichnet man Sprachen wie PHP oder Javascript nur als objektbasiert, weil sie eben genau keine Polymorphie unterstützen.
Du kannst mit Objekten arbeiten, von denen Du nur weißt, welche gemeinsame Basisklasse sie haben, und welche Methoden sie gemeinsam haben. Was konkret dahintersteht ist einem oft relativ egal. Bzw. man steuert an anderer Stelle, mit welchen Objekten überhaupt dort gearbeitet wird.

Der wichtigste Unterschied ist ja auch, dass strukturierte Programmierung Top-Down ist und OOP Bottom-Up. Bei Top-Down fängst Du vom Gesamtproblem an, Dir Teilprobleme zu überlegen, entwirfst immer feinere Strukturen um die Probleme zu lösen. Bei OOP dagegen entwirfst Du zuerst kleine Strukturen (nicht im C-Sinn), fügst diese Zusammen und lässt sie zu immer größeren Gebilden werden, bist die Endaufgabe lösbar ist.
Geht man an OOP mit dem Top-Down-Gedanken ran, könnte man das 'mal eben' (starke Übertreibung ) als Designfehler auslegen. Es ist halt eine völlig andere Denkweise und erfordert viel Übung, seine Denkstrukturen umzukrempeln.


Naja, ich will letztendlich nicht sagen, dass das eine besser ist als das andere. Hast Du ja selbst gesagt, dass es 'nur' eine andere Vorgehensweise ist. Ich fand einfach nur, dass Du das 'OOP-Modell' von Morgoth stark nach den Regeln der strukturierten Programmierung auseinander genommen hast. Deshalb auch meine 'Behauptung'.

Ich glaube, das hat jetzt so langsam nichts mehr mit dem eigentlichen Thema zu tun Vielleicht sollten wir mal in einem anderen Thread weiterdiskutieren

 

[KRambo]

Re: Wie Programmieren lernen?

Irgendwie wurde das Thema des Threads in den letzten Posts leicht verfehlt, da es hier eigentlich drum geht, mit welcher Sprache man anfängt und nich was OOP iss und warum man es benutzen (nicht) benutzen soll

 

[Morgoth]

Re: Wie Programmieren lernen?

Ich glaube nicht, dass das Thema dadurch verfehlt wird. Es ist unheimlich wichtig, dass man sich vorher darüber klar wird, mit was man programmiert.

ich kenne programmierer, die zaubern die fettesten programme in plain c,

Wenn man so ein Typ ist, hat man meist tierische Probleme mit OOP. Ich behaupte mal das </Life> einer aus der Richtung ist, ich bin eben eher der OOP-Typ, dem gar nichts zu abstrakt sein kann. Daher die Differenzen.

Nur wenn sich der Threadersteller letztendlich für C entscheidet, aber halt eher der OOP-Typ ist, kommt großer Schmodder bei raus. Umgekehrt genauso.

Also vorher überlegen, was man ist, vielleicht mit 2 Sprachen (einer imperativen und einer objektorientierten) anfangen und experimentieren, wenn man mit der einen besser klar kommt, ist man halt der entsprechende Typ.

Gruß
Morgoth

 

[Green Mamba]

Re: Wie Programmieren lernen?

so, ich hab den thread mal aufgeteilt, weil die diskussion doch eigentlich gar nix mehr mit der frage zu tun hatte "womit programmieren lernen".

Der wichtigste Unterschied ist ja auch, dass strukturierte Programmierung Top-Down ist und OOP Bottom-Up. Bei Top-Down fängst Du vom Gesamtproblem an, Dir Teilprobleme zu überlegen, entwirfst immer feinere Strukturen um die Probleme zu lösen. Bei OOP dagegen entwirfst Du zuerst kleine Strukturen (nicht im C-Sinn), fügst diese Zusammen und lässt sie zu immer größeren Gebilden werden, bist die Endaufgabe lösbar ist.

dazu muss ich noch was loswerden, bei der planung für oop sind beide richtungen gleichberechtigt. man kann auch erst mal sehen was brauche ich (meinetwegen ein paar black-boxes), und diese teile dann immer weiter verfeinern (klassendiagramm), bis man schlussendlich sein fertiges ood-diagramm hat.
also man ist nich an eine richtung gebunden.

 

[ag3nt]

Re: Wie Programmieren lernen?

...Für die ganz kleinen Einheiten ist es einfach nur Blödsinn, sie mit Klassenelementen zu überladen. Wenn du das WIRKLICH so konsequent durchführst wie du es sagst kannst du gar nicht erst anfangen, weil dir die einfachsten Elemente fehlen. Du kannst nicht das imperative "a-b" verwenden, sondern musst stattdessen "a.substract(b)" benutzen. Dafür musst du aber erstmal a und b initialisieren... Statt 42-18 hiesse es also: new ((new Integer(42)).substract(new Integer(18))). DAS nennst du dann ein tolles Konzept?...

mal ganz dumm gefragt, wo soll das problem liegen? das ist sogar deutlich logischer als a-b. du willst das ergebnis der rechenoperation (42-18) im speicher haben und brauchst dazu für die rechnung einen zwischenspeicher für die beiden zahlen. ist doch folglisch absolut logisch und nachvollziehbar. in pascal/delphi ist es genauso, dort musst du den speicher auch ersteinmal zuweisen damit etwas in der art c:= a-b; herauskommt. und als gegenbeispiel wäre das ganze kein integer wert sondern ein mathematischer-vektor (extrem beispiel 100 dimensionen) so sähe die oop version immer noch so aus a.substract(b).

 

[Morgoth]

Re: Wie Programmieren lernen?

so sähe die oop version immer noch so aus a.substract(b).

Wobei das OOP verschiedene Möglichkeiten bietet. a.substract(b) ist eine Sache, richtig interessant wird es, wenn der Operator "-" selber ein Objekt ist.
In C++ kennt man ja die Möglichkeit per operator +(class A, class A) einen Operator umzuschreiben. Im Hauptprogramm wäre das dann eine Nachricht an das zu manipulierende Objekt: a=b+c, das Programm schickt die Nachricht "+" an "a", um doch bitte b und c miteinander zu addieren (oder was auch immer "+" hier bedeutet, da ist man ja vollkommmen frei).
Anders, wenn "+" und "=" als Objekte aufgefasst werden. Dann ließe sich diese Anweisung so übersetzen: das Programm weist das Objekt "+" an, die beiden Objekte "a" und "b" zu addieren, und das Ergebnis an das Objekt "=" weiterzugeben. Dieses Objekt hat keine andere Aufgabe als das Ergebnis der vorhergehenden Operation in das Objekt "a" zu packen.
Aufgabe des Programmierers ist es noch, eine neue Kind-Klasse der rein virtuellen Klasse "+" zu erstellen, die diese Aufgabe für seine erstellte Klasse ausführt. Das gleiche für die Klasse "=".

Schwer zu verstehen? Klar, gebe ich zu, das erfordert einige Hirnwindungen, bis man das Prinzip verinnerlicht hat. Aber plötzlich erkennt man: ah ja, natürlich. Ich mache es doch im real life auch nicht anders.
Nochmal das Beispiel mit der Werkstatt (ein bisschen überarbeitet):
ich gebe das Objekt "Mein Auto", das eine Instanz der Klasse "Auto" ist, die wiederum eine Kind-Klasse von "Fahrzeug mit vier Rädern ist", ...,, welches im Zustand "defekt" ist, an das Objekt "Fachwerkstatt meines Autohändlers", die eine Instanz der Klasse "Fachwerstatt" ist, ..., um den Zustand in "nicht defekt" umzuwandeln.
Dabei ist "Fachwerkstatt meines Autohändlers" das Operator-Objekt, und "Typ der mir das Auto wiedergibt und dann 1000€ abknöpft" das Zuweisungs-Objekt.
Natürlich wird niemand so komplex denken, wenn er sein Auto zur Werkstatt fährt. Aber trotzdem ist es objektorientiert, denn in der Kurzform sieht es so aus:

- Auto zur Werkstatt
- Werkstatt macht heile
- Auto wiederholen

2 Objekte, die miteinander interagieren. Oder als Anweisung geschrieben:

Auto=Werkstatt(Auto);

Und nochmal: es ist mir dabei völlig egal, was die Werkstatt mit dem Auto macht, es sollt nur heile da wieder rauskommen.

Wenn der Operator eine Nachricht ist, sieht es so aus:

- Befehl an Werkstatt: "mach Auto heile!"
- Werkstatt macht heile
- Befehl an mich: "hol Auto ab!"
- ich hole Auto ab

Auch eine Möglichkeit. Manchen mag das eher liegen, ich habe mich eher mit der oberen Variante angefreundet. Beides ist aber gleichwertig, und das wichtigste daran ist immer noch: die Kapselung. Wie etwas passiert ist egal, wichtig ist nur das es passiert.

Aber wie hat Morgoth das so schön erklärt: Bei OOP muss man nicht verstehen, wie es funktioniert, Hauptsache ist man kann es benutzen.

Ja, genau so ist es.

Gruß
Morgoth