Objektorientiert denken?
-
So in etwa, jo:
http://de.wikipedia.org/wiki/Objektorientierte_Programmierung
-
Mentras schrieb:
... ein paar Posts, in denen stehen: "Du musst objektorientiert denken!"
Wer das sagt, der kanns selber nicht.
-
Den Wiki Link lese ich mir grad durch
Danke !Soo, die kommende Aussage ist jetzt mit "true" || "false" zu beantworten.
Objektorientierung sind Strukturen, sie dienen der Erleichterung beim coden?
In Visual Basic hab ich mit Structure solche "Klassen" definiert
Kann ich das damit vergleichen?
-
Mentras schrieb:
Objektorientierung sind Strukturen, sie dienen der Erleichterung beim coden?
true
Mentras schrieb:
In Visual Basic hab ich mit Structure solche "Klassen" definiert
Kann ich das damit vergleichen?true
Dazu noch jede Menge Philosopie, wie "Der Mensch denkt in Begriffen" und "Weil die Kuh ein Säugetier ist, hat sie alle Eingenschaften, die Säugetiere haben, insbesondere sieben Halswirbel", und ein Stil, der es schafft, daß man in seinen Compiler Code klopft, der so aussieht, als würde man Brehms Tierleben schreiben, aber am Ende kommt überraschenderweise ein 3D-Shooter raus.
-
Hahaha
Okay, dann muss ich mich bedanken. Danke Volkard,HellFreezesOver und Kóyaánasqatsi.
Lg Mentras
-
Ich muß Dir auch danken. Durch die richtigen Fragen zum richtigen Zeitpunkt hast Du mich dazu gebracht, etwas wie ich finde sehr Wichtiges endgültig zu begreifen, das schon sehr lange in mir heranwuchs.
-
Ahh, das freut mich
-
Wenn du 10 Leute fragst was "objektorientiert denken" heisst, wirst du vermutlich 10 verschiedene Antworten bekommen.
Für mich bedeutet "objektorientiert denken", strenggenommen, dass man alles in Form von Objekten betrachtet, wenn man übers Programmieren nachdenkt.
Das heisst nicht nur Daten werden zu Objekten verschiedener Klassen zusammengefasst, sondern auch Funktionen, Algorithmen etc. sind Objekte. Selbst Klassen sind Objekte.
Sämtliche "Aktionen" die man durchführen kann, werden damit zu "Operationen auf Objekten" - was meist "Methoden" genannt wird - und sind genaugenommen auch wieder nur Objekte.----
Meine etwas praxisnähere Variante deckt sich schon mehr mit dem was volkard geschrieben hat.
BTW: C++ ist ziemlich stark "multi paradigm", und der "moderne" C++ Stil weicht ziemlich stark vom "strengen" objektorientierten Denken/Design ab.
-
hustbaer schrieb:
...
Laß mich raten: Du liebst Smalltalk.
-
hustbaer schrieb:
Für mich bedeutet "objektorientiert denken", strenggenommen, dass man alles in Form von Objekten betrachtet, wenn man übers Programmieren nachdenkt.
Das heisst nicht nur Daten werden zu Objekten verschiedener Klassen zusammengefasst, sondern auch Funktionen, Algorithmen etc. sind Objekte. Selbst Klassen sind Objekte.
Sämtliche "Aktionen" die man durchführen kann, werden damit zu "Operationen auf Objekten" - was meist "Methoden" genannt wird - und sind genaugenommen auch wieder nur Objekte.<irrelevant>
Diese Sichtweise hat sicher ihre Berechtigung. Ich habe auch mit ihr experimentiert. Übertrieben und aufs Deutsche übertragen wäre das ungefähr so, als würde ich lauter Hauptwörter oder Ding-Bezeichnungen denken. Ich Vermutung Letztgenanntes Negation Sinn Alternative Zweck. Überraschung Letzgenanntes Kreation Spaß Vielzahl. Du Idee Ich Konsequenz Dank. Albernheit.
Ich will eigentlich so proggen, wie ich denke, deutsch, englisch, spanisch, egal, aber nicht chinesisch, das würde mich nur verwirren. Ich glaube, daß ich ganz gut damit fahre, Operationen und Objekte normalerweise zu trennen. Natürlich kann es sinnvoll sein, gelegentlich Operationen als Objekte zu benutzen, wie im deutschen auch, wenn man von dem Programmieren redet.
Und die Methodenaufrufe als Nachrichtensendungen zu sehen, womit die Nachrichten total gegenständlich werden, hat mich in dem einen oder anderen Projekt schon weit voran gebracht.
</irrelevant>
Das sollte man wohl machen, wie man will. Je nach Sprache und Projekt ein wenig flexibel zu sein, ist bestimmt kein Fehler.
-
volkard schrieb:
hustbaer schrieb:
...
Laß mich raten: Du liebst Smalltalk.
Nein
Aber ich verstehe nicht ganz, wieso viele objektorientierte Sprachen so wenig konsequent sind, bei Dingen, wo es leicht ginge (=keine Performance kosten würde, wie z.B. bei Type-Infos & Funktions-Typen).
-
volkard schrieb:
hustbaer schrieb:
...
<irrelevant>
Natürlich kann es sinnvoll sein, gelegentlich Operationen als Objekte zu benutzen, wie im deutschen auch, wenn man von dem Programmieren redet.
Und die Methodenaufrufe als Nachrichtensendungen zu sehen, womit die Nachrichten total gegenständlich werden, hat mich in dem einen oder anderen Projekt schon weit voran gebracht.
</irrelevant>
Das sollte man wohl machen, wie man will. Je nach Sprache und Projekt ein wenig flexibel zu sein, ist bestimmt kein Fehler.So inetwa sehe ich das auch.
Ich denke mit dem Paradigma "Objektorientiert" kann man viel anfangen. Bestimmte Dinge werden dadurch (viel) einfacher, bzw. klarer - wenn man vorher noch nicht in solchen Bahnen gedacht hat.
Andere Dinge werden dadurch wohl unnötig verkompliziert bzw. "aufgeblasen". Von daher bin ich mit C++ als multi-paradigm Sprache grundsätzlich recht angetan.
Allerdings kommt mir der objektorientierte Teil manchmal etwas zu kurz. Man sehe sich bloss man type_info an, und was man damit alles nicht machen kann. Oder die nicht vorhandene Komplexitäts-Schranke für dynamic_cast -- weswegen mir jedesmal etwas mulmig wird, wenn ich dynamic_cast an Stellen nutze, die möglicherweise sehr sehr oft durchlaufen werden. Bzw. die ganzen tollen Sachen der Standard-Library (Algorithmen, Container), wo ich bis heute nicht verstehe, warum es keine (standardisierten) abstrakten Adapterklassen dafür gibt? enumerable<T>, iterator<T>, callable<T> - unabhängig vom Container/... -- hätte ich schon oft verwenden können. Einfach um "hier endet der Template-Wahn" Grenzen ziehen zu können. Templates sind zwar toll, aber gewisse Dinge müssen die (Geschwindigkeits-) Vorteile von Templates nicht nutzen, und dann sehe ich auch keinen Grund, dass Code zigfach vorliegt, der nur einmal nötig wäre.
Klar kann man sich einiges von dem was ich hier aufgelistet habe selbst stricken. Und um anderes herumarbeiten. Bloss das ist viel Arbeit (die IMO nicht nötig wäre), und noch dazu wird dann erst wieder in jedem Projekt wo soetwas gemacht wird das Rad neu erfunden. Was wiederum die Interoperabilität beeinträchtigt.
Leider scheine ich zumindest mit den abstrakten Adaptern recht allein dazustehen, sonst gäbe es die schon lange in der Boost. Andere Dinge (eben bind, function, lambda) gibt es schon länger in der Boost, und werden im neuen Standard endlich "offiziell", aber das geht leider alles recht *gähn* langsam *schnurch*
-
Ich würde einfach sagen: Objektorientiert denken bedeutet, Gegenstände, die von Interesse sind, zu Gebilden zu abstrahieren, die sowohl einen Zustand als auch Funktionen bieten. Der Ablauf eines Programms entspricht dann dem Versenden von Nachrichten zwischen den Gebilden.
