Nutzt mein Programm die O.O.P. oder nicht?
-
LukasBanana schrieb:
Konrad Rudolph schrieb:
...In QB habe ich das auch schon gemacht...
Mal ganz neben bei: QB, "QuickBasic" wenn ich nicht irre (von Windows), ist das nicht eine schon eher ausgestorbene Programmiersprache?
@Konrad Rudolph: "Verwändest du diese Programmiersprache immer noch?"Also, um das klarzustellen: QBASIC (bzw. QuickBasic, habe ich beides schon verwendet, sind aber zwei Sachen) habe ich das letzte Mal vor fast einem Jahrzehnt programmiert, und auch damals nur unter DOS, nie unter Windows. Das geht zwar auch, aber warum sollte man das tun?

-
Konrad Rudolph schrieb:
denn das würde ja bedeuten, dass das Benutzen von Überladung (ist auch Polymorphie) ebenfalls Objektorientierung wäre.
Redefinition ist kein Polymorphismus und Überladung ist kein Polymorphismus, aber es stimmt schon, dass es nicht unbedingt objektorientierte Programmierung sein muss, wenn man eines der objektorientierten Paradigmen benutzt, zum Beispiel ist Datenkapselung natürlich auch in anderen Konzepten der Programmierung als Paradigma vertreten.
-
Konrad Rudolph schrieb:
LukasBanana schrieb:
Konrad Rudolph schrieb:
...In QB habe ich das auch schon gemacht...
Mal ganz neben bei: QB, "QuickBasic" wenn ich nicht irre (von Windows), ist das nicht eine schon eher ausgestorbene Programmiersprache?
@Konrad Rudolph: "Verwändest du diese Programmiersprache immer noch?"Also, um das klarzustellen: QBASIC (bzw. QuickBasic, habe ich beides schon verwendet, sind aber zwei Sachen) habe ich das letzte Mal vor fast einem Jahrzehnt programmiert, und auch damals nur unter DOS, nie unter Windows. Das geht zwar auch, aber warum sollte man das tun?

Ja das stimmt, ich habe es halt nun mal unter Windows laufen weil ich darauf mein aller erstes Programm geschrieben habe! Also zum anfangen eben, und in den vorhergehenden Beiträgen klang es so als würdest du immer noch darauf programmieren!

Außerdem dachte ich QBasic == QuickBasic?!
-
Konrad Rudolph schrieb:
Why not?
Weil's komplett schwachsinnig ist, deswegen.
Konrad Rudolph schrieb:
Ich wollte mich aber eigentlich nicht zu sehr an der technischen Realisierung festgeklammert, in diese Position werde ich gerade hineingedrängt.
Also bitte.
Konrad Rudolph schrieb:
Ich wollte nur darauf hinweisen, dass längst nicht alles OO ist, nur weil es Klassen benutzt. ...
Stimmt. (edit: heißt natürlich nicht dass man zwangsläufig virtuelle Methoden zur OOP nutzen muss.)
-
finix schrieb:
Konrad Rudolph schrieb:
Why not?
Weil's komplett schwachsinnig ist, deswegen.
Grmpf. Weißt Du, sowas ärgert mich. Das ist nämlich Rumtrollen. Wenn das ganze fundiert sein soll, was ich glaube, dann versuch mal, weniger extreme Aussagen mit mehr Begründung zu ummanteln. In der aktuellen Form ist es nämlich ziemlich unakzeptabel und in keiner Hinsicht förderlich.
Wenn Du denkst, dass man ein technisches Konzept vollkommen losgelöst von der technischen Umsetzung sehen kann, dann sei Dir das natürlich freigestellt. Aber wir wollen hier doch Wissenschaft und nicht Religion betreiben. Dazu gehört irgendwie auch eine wissenschaftliche Argumentation.
-
nillable schrieb:
Konrad Rudolph schrieb:
denn das würde ja bedeuten, dass das Benutzen von Überladung (ist auch Polymorphie) ebenfalls Objektorientierung wäre.
Redefinition ist kein Polymorphismus und Überladung ist kein Polymorphismus, ...
Sorry, aber das scheint mir eine relativ beliebige/individuelle/subjektive Definition von Polymorphie zu sein (erkennt man schon daran, dass eigentlich niemand von "Polymorphismus" redet in der Programmierung - in Mathe ist das natürlich ein definierter und gut benutzter Ausdruck)...
Der Verfasser postuliert a priori, dass Polymorphie immer erst zur Laufzeit "zuschlagen" darf ... und kommt dann zu dem "überraschenden" Ergebnis, dass alles Andere keine Polymorphie sei.Konrad ist aber beileibe nicht der einzige, der "Polymorphie" als umfassenderes Konzept versteht. Letztlich heißt Polymorphie nur "Vielgestaltigkeit" und meint, dass sich hinter einem Bezeichner unterschiedliche Identitäten verbergen.
Und so unterscheidet man eben zwischen Laufzeitpolymorphie (z.B. via virtual functions ... gibt aber auch andere Techniken) und Compilezeitpolymorphie (z.B. overloading, templates, ...) - egal, was irgendein FH-Dozent in 2002 mal geschrieben hat.
Gruß,
Simon2.
-
Konrad Rudolph schrieb:
Grmpf. Weißt Du, sowas ärgert mich. Das ist nämlich Rumtrollen. Wenn das ganze fundiert sein soll, was ich glaube, dann versuch mal, weniger extreme Aussagen mit mehr Begründung zu ummanteln. In der aktuellen Form ist es nämlich ziemlich unakzeptabel und in keiner Hinsicht förderlich.
Ja du hast Recht, vielleicht hätte ich das erläutern sollen, da es für dich scheinbar nicht offensichtlich ist. Hier also die Neufassung:
Es ist - IMAO - komplett schwachsinnig ein Konzept über eine mögliche (und komplett transparente) Implementierung einer Umsetzung (bzw vielmehr einer Interpretation) des Konzepts definieren zu wollen.
Ein Konzept wird technisch umgesetzt, nicht umgekehrt. Selbst wenn ein solches Konzept aus der Anwendung hervorgeht (a la Design-Patterns), steht keineswegs die Realisierung an sich im Vordergrund.
-
finix schrieb:
Es ist - IMAO - komplett schwachsinnig ein Konzept über eine mögliche (und komplett transparente) Implementierung einer Umsetzung (bzw vielmehr einer Interpretation) des Konzepts definieren zu wollen.
Leider ist diese Aussage irgendwie nicht viel besser, was eine Begründung anbelangt.

Ich möchte darauf hinweisen, dass es mir hier nicht prinzipiell um die tatsächliche technische Umsetzung geht. Also, dass im Hintergrund eine vtable sitzt, die dafür sorgt, dass zur Laufzeit die korrekte Methode aufgerufen wird. Wichtig ist nur, dass OOP einen Aufrufmechanismus postuliert, welcher zur *Laufzeit* in Abhängigkeit des Typs entscheidet, welche Methode aufgerufen wird. Hier bietet sich eine vtable als Implementierung nunmal an, genauso wie sich beim Konzept einer "Funktion, welche Daten eines Eingabetyps T1 auf Daten eines Ausgabetyps T2 abbildet" eventuell anbietet, diese über eine Hashtabelle zum implementieren. => Programmiertechnische Konzepte sind stark mit einer Umsetzung verbunden, da Effizient nunmal ein wichtiges Kriterium ist und darüber entscheidet, ob ein Konzept im echten Einsatz Erfolg hat. Das ist (laut (Ritchie|Thompson), vergessen, wer es war) auch der Grund für den Erfolg der Sprache C: Das hier umgesetzte Konzept der Zeiger ist ein *gutes* Modell der zugrundeliegenden Hardware. Das Konzept war dermaßen stark an die technische Umsetzung gebunden, dass jede theoretisch machbare andere Umsetzung Quatsch wäre.
So. Fazit: Du sagst, es sei Schwachsinn, ein Konzept über ihre technische Umsetzung definieren zu wollen. Ich sage: Es ist (in der Informatik) Schwachsinn, ein Konzept ohne Hinblick auf ihre technische Umsetzung zu definieren, denn ein solches Konzept ist in der Praxis nichts wert.
Ein Konzept wird technisch umgesetzt, nicht umgekehrt.
Genau das halte ich für falsch. Ich interpretiere fast alle mir bekannten, erfolgreichen Konzepte so, dass sie als Zusammenspiel aus Theorie und Umsetzung entstanden sind.
-
Konrad Rudolph schrieb:
Leider ist diese Aussage irgendwie nicht viel besser, was eine Begründung anbelangt.

Wenn du nicht mit mir übereinstimmst dann sag das auch einfach so.
Konrad Rudolph schrieb:
Ich möchte darauf hinweisen, dass es mir hier nicht prinzipiell um die tatsächliche technische Umsetzung geht.
Dafür reitest du aber immer noch, weiterhin unaufgefordert, ganz schön darauf herum.
Konrad Rudolph schrieb:
Ein Konzept wird technisch umgesetzt, nicht umgekehrt.
Genau das halte ich für falsch. Ich interpretiere fast alle mir bekannten, erfolgreichen Konzepte so, dass sie als Zusammenspiel aus Theorie und Umsetzung entstanden sind.
Man kann (und sollte) ein Konzept mit Hinblick auf mögliche Implementierungen entwerfen; dennoch wird das Konzept keineswegs darüber definiert.
-
finix schrieb:
Konrad Rudolph schrieb:
Leider ist diese Aussage irgendwie nicht viel besser, was eine Begründung anbelangt.

Wenn du nicht mit mir übereinstimmst dann sag das auch einfach so.
Habe ich. Hier meinte ich aber etwas anderes, nämlich dass keine Begründung da ist. "Ist so" ist eben keine Begründung.
-
Hallo LukasBanana,
um hier noch mal konkret auf dein Beispiel einzugehen und nicht nur über die Definition von OOP zu diskutieren, ein paar Anmerkungen von mir.
So wie dein C++ Code jetzt aussieht, könnte man ihn auch relativ leicht in C umsetzen (Klasse als Struktur und die Methoden als einzelne Funktionen).
Wenn du dich näher mit C++ auseinandersetzt, wirst du erkennen, daß es noch mehr Möglichkeiten gibt, der OOP näherzukommen...
Wenn du das Window-System weiter ausbauen willst, wirst du sicherlich irgendwann zu dem Punkt kommen, wo du spezielle Windows erstellen willst.
Dafür bietet sich dann die Klassenableitung an, z.B.class SpecialWindow : public Window { }Nun möchte dieses Spezialfenster aber noch mehr zeichnen als ein Standard-Fenster, z.B. ein Hintergrundbild oder einen anderen Rahmen.
Dazu kannst du dann sogenannte virtuelle Methoden benutzen, d.h.
virtual void Draw();Nun kannst du die SpecialWindow::Draw Methode "überschreiben", z.B.
class SpecialWindow : public Window { public: virtual void Draw(); }; // in der Implementierungsdatei void SpecialWindow::Draw() { Window::Draw(); // erst Standard-Fenster zeichnen DrawBackgroundImage(); // nun Hintergrundbild zeichnen }Nun müßtest du deinen Vector nur noch so abändern, daß er Pointer statt Instanzen verwaltet, und schon kannst du beliebige Windows erstellen und zeichnen (nun benötigst du auch new und delete):
std::vector<Window *> vWindows; Window *window = new Window(); // hier z.B. weitere Attribute setzen vWindows.push_back(window); Window *special = new SpecialWindow(); vWindows.push_back(special); // nun alle Fenster zeichnen (lassen) for(std::vector<Window *>::iterator it = vWindows.begin(); it != vWindows.end(); ++it) { (*it)->Draw(); // da jetzt Zeiger auf Windows im vector gespeichert sind (man kann auch (**it).Draw() schreiben) } // jetzt noch die Windows aus dem vector löschen for(std::vector<Window *>::iterator it = vWindows.begin(); it != vWindows.end(); ++it) { delete *it; } vWindows.clear();Mit all den obigen C++ Techniken kannst du wunderbar objektorientiert programmieren.
Viel Spaß noch beim C++ lernen und programmieren...
-
Vielen Dank für deine Antwort "Th"!

Nur noch mal eine kurze Frage:
Was genau bewirkt das "virtual"? Ich bin in meinem Buch noch lange nicht durch und die Klassen Programmierkenntnisse habe ich von meinem Onkel aber eben noch nicht alles!Kann mir das jemand sagen, was "virtual" bewirkt?
-
Oh Mann, du kannst nur ein Troll sein...
-
Lies doch einfach in deinem Lehrbuch weiter. Warum sollen wir dir virtual erklären? Wenn wir etwas erklären, dann nur wenn jemand etwas nicht verstanden hat, trotz Lehrbuch. Vielleicht verstehst du es ja auch auf Anhieb, wenn du in deinem Buch soweit bist, und wir können uns ellen lange Erklärungen für jeden einzelnen Forumsuser ersparen.
-
Was hast du gegen Anfänger! Dafür ist doch auch das Forum da oder etwa nicht?
Wenn du, "finix" schon die Zeit findest einen Beitrag zu schreiben kannst du doch auch genau so gut einfach meine Frage beantworten, damit währe mir mehr geholfen!Sorry, aber solche Beiträge sind noch sinnloser als blöde Fragen!

(Es gibt keine blöden Fragen nur blöde Antworten)@finix: "Hast du nun eine Antwort oder nicht?"
-
Vielleicht ist virtual nicht mit einem Satz erklärt?
Weil da mehr zusammen hängt, worüber andere ganze Bücher schreiben.
-
Ist das mit dem "virtual" wirklich so umfangreich???

Oder kann mir jemand einen Link zu einer Erklärung mit "virtual" geben, wenn das nicht so schnell zu erklären ist?
-
-
LukasBanana schrieb:
Oder kann mir jemand einen Link zu einer Erklärung mit "virtual" geben, wenn das nicht so schnell zu erklären ist?
-
Danke "vista"!
