OOP auf ASM

[Michael (Gast)]

Hallo,

irgendwie hab ich eine Gedankenblockade. Also wenn ich ein Programm in
z.B. JAVA schreibe dann hab ich meine Objekte und Methoden etc.
Die ganze OOP wird ja als ein System gesehen das sich in einer Hirachie
abbilden läßt.
Dann wird compiliert und dam in der RE gestartet..

Aber im Endeffekt müssen aus dem ganzen Bytecode in der RE ja wieder
Assembler-Befehle entstehen mit denen die CPU "arbeiten" kann.

Und jetzt häng ich: was bleibt mir da eigentlich von der OOP über.
Diesen Übergang kann ich nicht nachvollziehen.

Hat wer ein paar erklärende Worte für einen OOP Anfänger.

Danke Michael

[A.K. (Gast)]

Du scheinst OOP als eine irgendwie magische Sache zu betrachten, die
sich nicht in konkrete Ausführungsanweisungen übersetzen lässt, weil
diesen verständlichen Ausführungsanweisungen der magische Charakter
fehlt.

Kleiner Tip: Der erste C++-Compiler hat nicht Assembler-Code sondern
C-Code produziert. Vielleicht hilft dir das weiter.

Ansonsten habe ich gewisse Schwierigkeiten, dein Problem zu erkennen.
Hast Du mal ein Beispiel?

[Bri (Gast)]

OOP ist nur ein weiteres Abstraktionslevel, mehr nicht. Deshalb muss der
Prozessor nicht direkt OOP unterstützen.

[Gerhard Gunzelmann (Gast)]

Hallo Michael

das hast Du richtig beobachtet. OOP stellt vom Verständnis her auch ein
Problem dar. Der uP arbeitet nicht objektorientiert sondern
aktionsorinetiert. So wie man früher mit der DOS-Konsole gearbeitet
hat. Da gibts Befehle wie z.B. Copy: copy <Pfad\Datei> <Pfad\Datei>.
Das funktionierte gut, solange es kein Windows mit seiner Oberfläche
gab. Ein Icon am Bildschirm repräsentirt jetzt aber ein Objekt, also
keine Aktion. Das machte OOP notwendig. Ein Fortschritt in der
Programmierung durch OOP als solchen gibts nicht, ausser dass alles
aufgeblasen wird. Und zuletzt wird - wie du das ja schon erkannt hast-
wieder die alte aktions-orientierte Programmierung daraus.

Gerhard

[Tobi H. (tobi-)]

Wenn man als Beispiel mal C++ nimmt, dann wird aus einer Klasse
eigentlich garnichts. (Virtuelle Funktionen jetzt mal aussen vor) Der
Compiler benutzt die Klassendifintion für die Prüfung, ob
Methodenaufrufe gültig sind oder nicht. Danach wird die Klasse einfach
in normale langweilige C-Funktionen zerstückelt, die nach einem
bestimmten Muster benannt sind, dass ihr Klassenzugehörigkeit und
Parameter angibt. D.h Klassen sind prinzipiell nur ein Sprachkonstukt,
das 100%ig in nicht-OOP überführt werden kann.

[Michael (Gast)]

oh es gibt schon Antworten - danke -

d.h. OOP ist eigentlich nur eine schicke Verpackung.
Bei meinen ASM Programmen ("nur" µC) hatte ich eigentlich nie das
Gefühl das mir eine Möglichkeit der Programmgestaltung fehlte.
(Das oftgehörte Argument, daß man die Sachen nur "einmal" erfinden
muß hab ich nie nachvollziehen können. In ASM hab ich ja ebenso die
Routinen je nach möglichkeit mehrfach ausgenutzt)

Dann hab ich mir JAVA angesehen (für mich der erste OOP-Kontakt) und
ich hab mir die Frage gestellt warum das so toll sein soll. Ist halt
ein anderer Stil aber teilweise wird OOP ja wie eine Religion
behandelt.

Jetzt wo ich langsam beginne zu verstehen wie OOP aufgebaut ist kommt
mir der "aha - dafür also" - Effekt abhanden.
- Aber wie bereits erwähnt - ich bin im Anfangsstadium also für alles
offen.

Michael

[A.K. (Gast)]

"OOP ist eigentlich nur eine schicke Verpackung"

Ungefähr in dem Sinn, in dem C nur eine schöne Verpackung für
Assembler, und Assembler nur eine schöne Verpackung für
Maschinensprache ist.

Man kann OOP zwar auch zur Modularisierung traditioneller
Programmiersprachen benutzen, dann stimmt das.

Aber der Ansatz greift natürlich viel zu kurz. Der Witz liegt eher bei
heterogenen Datenstrukturen und Ableitung und Spezialisierungen von
Klassen. Der ganze Bereich von Collection Classes ist ziemlich typisch
für OOP und ziemlich untypisch für klassische Sprachen.

Freilich zeigen Java oder C++ nicht ganz den fundamentalen Ansatz von
OOP, weil die immer noch zwischen Skalaren und Objekten unterscheiden.
Und auch zwischen Code und Daten. Wer wirklich OOP verstehen will,
sollte man einen Blick in Smalltalk werden. Code als Objekt. Da wird's
interessant.

[Karl H. (kbuchegg)]

> d.h. OOP ist eigentlich nur eine schicke Verpackung.

Eigentlich ist das meiste 'nur eine schicke Verpackung'.
Auch Assembler ist nur eine schicke Verpackung. Auch
Maschinensprache ist nur eine schicke Verpackung.
Eine CPU muss erstaunlich wenig koennen um alles berechenbare
auch tatsaechlich berechnen zu koennen. Google mal
nach 'Turing Maschine'. Das ist die allereinfachste 'CPU'
die du dir vorstellen kannst. Und trotzdem kann sie alles
was ueberhaupt berechenbar ist auch berechnen.

Wo liegt also der Unterschied?
Der Unterschied liegt in der 'Geschwindigkeit der Programmierung',
'der fehlerfreihet der Programmierung' und was immer wichtiger
wird 'der Handhabbarkeit von grossen Projekten'. Ein Projekt
mit 1 Mio Codezeilen in C++ ist ein mittelgrosses Projekt. Sowas
kann man mit einer guten Mannschaft noch problemlos handhaben.
Dasselbe Projekt in Assembler, da werden dann geschaetzte 4 bis
8 Mio Codezeilen draus, ist aber von derselben Mannschaft nicht
mehr handhabbar.

OOP ist nichts anderes als das Prinzip des 'Hiding' (Verstecken
von Informationen) ins extrem getrieben. Auch in C kann man
'Hiding' betreiben, nur gibt es keine Sprachmittel, wie ich
einen anderen Programmierer daran hindern kann in den internals
einer Datenstruktur rumzupfuschen. OOP-Sprachen erlauben mir das:
Ich kann die Internals hinter einer Mauer verstecken. Zugang
zu den 'Internals' ist nur ueber gesicherte Zugänge möglich.