Ich programmiere schon seit ein paar Jahren C und wrüde sagen, dass ich
auch ganz gut darin bin. Dieses Semeser habe ich eine C-Lehrveransatung
mit der Höchstunktezahl abgeschlossen und habe nächstes Semester gibt es
die Möglichkeit dass ich eine Lernveranstaltung in der man C++ lernt als
Freifach absolviere, das würde mich auch interessieren. Bevor ich nich
dazu anmelde wollte ich mir noch kurz euere Meinungen hohlen, wie
schwierig ihr es einshätzt C++ noch dazuzulernen.
Danke für euere Meinungen.
Die schlechte Nachricht:
alles zu C++ lernen = keine Chance, das dauert ewig
Die gute Nachricht:
Man braucht von C++ nicht alles gleichzeitig, sondern kann sich
stückweise rantasten.
Also template-Funktionen, Operatoren überladen, OO, STL etc. kann man
nacheinander angehen.
Das langwierigste ist sicher, die OO-Denkweise zu verinnerlichen.
Student schrieb:> Bevor ich nich> dazu anmelde wollte ich mir noch kurz euere Meinungen hohlen, wie> schwierig ihr es einshätzt C++ noch dazuzulernen.
Der C++-Standard hat ca. 1500 Seiten. Ziemlich komplexe Syntax.
Im Gegensatz zu C, behaupte ich, kann man diese Sprache niemals
vollständig beherrschen.
Scott Meyers - einer der heiligsten C++ Gurus - hat mal auf einer
Konferenz gesagt, er wünscht sich eine Sprache, wo man Leute wie ihn
nicht benötigt ;-) Er hat viele Bücher über die unendlichen Fallstricke
verfasst.
Lass dich bitte von den Uni-Klausuren und "Voller Punktzahl" nicht
betrügen. Es ist war anderes in Großprojekt mit mehreren tausend Zeilen
Code C wiederverwendbar zu beherrschen als ein paar
Colaautomaten-Funktionen in einer 90-Minütigen Klausur zu tippseln.
c anteile findest du in c++ und c#.
die sache ist, dass man in der regel nicht alles gleich gut beherrschen
kann.
kannst du das eine gut, wird das andere etwas verdrängt.
c sollte man für den embedded bereich beherrschen und c++ oder c#
für den pc bereich für objektorientierte programmierung.
besuche den c++ kurs. egal ob schwer oder leicht.
die sprachen sind nur werkzeuge.
je besser du ein werkzeug beherrscht, desto besser für dich und dein
produkt.
Klaus Wachtler schrieb:> Das langwierigste ist sicher, die OO-Denkweise zu verinnerlichen
Als ob, das ist noch schön einfach und leicht vorstellbar. Warum immer
alle Angst vor OOP haben verstehe ich nicht. Auch viele C-Programme
verwenden OOP, und man kann auch C++ ohne OOP nutzen.
Viel spaßiger als OOP ist die "richtige" Template/Meta Programmierung,
Speicherverwaltung, rvalue references, korrekte Exception Sicherheit bei
Meta Programmierung...
Allerdings sollte das natürlich nicht abschrecken, C++ zu lernen - diese
fortgeschrittenen Dinge braucht man nicht um schöne Anwendungen zu
programmieren, und im Endeffekt kann man mit C++ schnell und effizient
programmieren.
Auch allgemein lohnt es sich über den C-Tellerrand zu blicken, und neue
Programmierparadigmen zu lernen.
kaese schrieb:> Der C++-Standard hat ca. 1500 Seiten. Ziemlich komplexe Syntax.>> Im Gegensatz zu C, behaupte ich, kann man diese Sprache niemals> vollständig beherrschen.
Naja, das "Datenblatt" des Atmega1284 hat z.B. 659 Seiten. Trotzdem wird
hier ja auch von jedem Anfänger verlangt, es auswändig zu kennen...
;-)
Ratgeber schrieb:> Naja, das "Datenblatt" des Atmega1284 hat z.B. 659 Seiten. Trotzdem wird> hier ja auch von jedem Anfänger verlangt, es auswändig zu kennen...
Das ist nicht wahr. Niemand hat das je verlangt. Noch nichtmal hier.
Klaus Wachtler schrieb:> Das langwierigste ist sicher, die OO-Denkweise zu verinnerlichen.
Das allein würde mir schon arg zu denken geben ob diese Denkweise der
Weisheit letzter Schluß ist. Das Werkzeug sollte sich dem Menschen
anpassen, nicht umgekehrt.
Student schrieb:> Bevor ich nich> dazu anmelde wollte ich mir noch kurz euere Meinungen hohlen, wie> schwierig ihr es einshätzt C++ noch dazuzulernen.
Ich vermute dahinter versteckt sich "Objektorientiertes Programmieren am
Beispiel C++".
Objektorientiertes Programmieren (wie strukturiere ich ein Programm in
getrennte Einheiten die einen) lohnt sich, das Konzept ist aber nicht
auf C++ beschränkt. Gibt allerdings ein paar Kopfnüsse zu knacken.
C++ selber ist recht einfach, wenn du C beherrscht. Die meisten C
Programme sind auch C++ Programme.
Allerdings macht man einige Dinge in C++ anders als in C. Man hat mehr
Möglichkeiten,
a) um besseren Code zu schreiben
b) durch nicht Wissen schlechteren Code zu schreiben
c) einige komplizierte/mächtige Konstrukte durch einfache
Schlüsselwörter zu ersetzen (davon viele Schlüsselwörter um OOP
einfacher zu implementieren)
d) Mächtigere Funktionen um Code zu erzeugen / zu verändern
Schau mal, ob C++11 / C++14 Erwähnung findet. Durch die Erweiterung der
Sprache hat sich einiges geändert.
Gruß Felix
Ratgeber schrieb:> Naja, das "Datenblatt" des Atmega1284 hat z.B. 659 Seiten. Trotzdem wird> hier ja auch von jedem Anfänger verlangt, es auswändig zu kennen...
Es wird eigentlich nur verlangt, da auch reinzuschauen, wenn man eine
Frage hat, statt reflexartig hier zu posten und zu erwarten, daß andere
für einen die Stelle im Datenblatt raussuchen.
Moby AVR schrieb im Beitrag #3995305:
> Klaus Wachtler schrieb:>> Das langwierigste ist sicher, die OO-Denkweise zu verinnerlichen.>> Das allein würde mir schon arg zu denken geben ob diese Denkweise der> Weisheit letzter Schluß ist. Das Werkzeug sollte sich dem Menschen> anpassen, nicht umgekehrt.
Es ist genau anderes herum, als das, was du daraus schließt. OOP
beschreibt die Sache eigentlich in einer für den Menschen viel
gewohnteren Art. Deshalb wurde OOP ja überhaupt erst erfunden. Die
prozedurale Programmierung ist eher die an den Computer angepasste
Denkweise. Das Problem ist deshalb nicht OOP an sich, sondern der
Wechsel von prozeduraler Programmierung zu OOP. Wenn du die
Programmierung gleich mit OOP lernst, wirkt das alles ganz natürlich.
Wenn du aber schon prozedurale Programmierung gewöhnt bist, mußt du dich
erst wieder komplett umgewöhnen.
Dr. Sommer schrieb:> Warum immer alle Angst vor OOP haben verstehe ich nicht. Auch viele C-> Programme verwenden OOP,
Einige davon aber nicht so richtig, sondern nutzen ein paar Elemente
davon, teils ohne es wirklich zu merken.
Rolf Magnus schrieb:> Es ist genau anderes herum, als das, was du daraus schließt. OOP> beschreibt die Sache eigentlich in einer für den Menschen viel> gewohnteren Art.
Naja, es kommt schon auch auf die Art des Problems an.
LED-Blinken ist OO auch nicht einfacher als prozedural, im Gegenteil.
Das sieht man ja schon daran, daß Java sinnloserweise eine Klasse mit
einer public static void main-Methode braucht; das ist ja eine
Vergewaltigung von OOP für etwas, was von der Natur her nicht OO ist:
"fang hier an...".
Ab einer gewissen Komplexität hast du aber natürlich recht, aber das ist
nicht Mobys Welt.
Bernd K. schrieb:>> Naja, das "Datenblatt" des Atmega1284 hat z.B. 659 Seiten. Trotzdem wird>> hier ja auch von jedem Anfänger verlangt, es auswändig zu kennen...>> Das ist nicht wahr. Niemand hat das je verlangt. Noch nichtmal hier.
Schmeiss mal Google an und suche nach der Bedeutung von: ;-)
Humorloser Unhold du!!!
Und falls du's immer noch nicht geschnallt hast, der Autor dieser Zeilen
hat GESCHERZT.
Student schrieb:> Bevor ich nich> dazu anmelde wollte ich mir noch kurz euere Meinungen hohlen, wie> schwierig ihr es einshätzt C++ noch dazuzulernen.
Wie schon geschrieben: OOP-Programmieren lernen lohnt sich auf jeden
Fall! Auf einem PC oder für Android z.B. auch mit C# oder Java.
Aus den "Fehlern" die C++ gemacht hat, haben diese neueren Sprachen
gelernt, daher ist hier vieles einfacher, für µC jedoch weniger
geeignet.
Warum? Falls es um C++ auf einem µC geht, siehe:
http://scottmeyers.blogspot.de/2013/02/schulungsunterlagen-zur-anwendung-von-c.html
Das wäre dann die Pflichtlektüre vom Guru^^. Ich habe 2 Tage gebraucht,
um alles zu verstehen.
Aber ich denke, bei Dir wird es um Programmierung auf einem PC
(Linux/Windows/...) gehen, oder?
Klaus Wachtler schrieb:> Rolf Magnus schrieb:>> Es ist genau anderes herum, als das, was du daraus schließt. OOP>> beschreibt die Sache eigentlich in einer für den Menschen viel>> gewohnteren Art.>> Naja, es kommt schon auch auf die Art des Problems an.> LED-Blinken ist OO auch nicht einfacher als prozedural, im Gegenteil.
Ja, wer nicht über die blinkende LED hinaus blicken kann, kann mit OOP
natürlich nichts anfangen.
> Ab einer gewissen Komplexität hast du aber natürlich recht, aber das ist> nicht Mobys Welt.
Allerdings. Es kommt aber auch darauf an, wie stark man abstrahiert. Es
ist auch möglich, "zuviel OOP" zu machen und sich in nachher niemals
notwenigen Klassenhierarchien zu verkünsteln. Aber jedes
Programmierwerkzeug kann missbraucht werden. Wie hieß es so schön? You
can write FORTRAN in any language.
> Das sieht man ja schon daran, daß Java sinnloserweise eine Klasse mit> einer public static void main-Methode braucht; das ist ja eine> Vergewaltigung von OOP für etwas, was von der Natur her nicht OO ist:> "fang hier an...".
Deshalb finde ich es auch gut, daß C++ OOP nicht fest erzwingt, wie es
Java tut. Ähnlich unsinnig finde ich in Java diese Helper-Klassen, die
ausschließlich aus static-Methoden bestehen. Da wurde auch prozedurale
Programmierung in den OOP-Schuh gezwängt. Eine Klasse, die nicht
instanziiert werden soll und von der auch nicht abgeleitet werden soll,
ist für mich irgendwie widersinnig.
Rolf Magnus schrieb:> Eine Klasse, die nicht> instanziiert werden soll und von der auch nicht abgeleitet werden soll,> ist für mich irgendwie widersinnig.
Tja, wenn man keine namespaces hat :-)
Rolf Magnus schrieb:> Eine Klasse, die nicht> instanziiert werden soll und von der auch nicht abgeleitet werden soll,> ist für mich irgendwie widersinnig.
Naah, die sind schon sinnvoll. Wenn eine klasse ausschließlich mit
statischen Methoden auskommt, muss sie weder instanziierbar noch
ableitbar sein...
Rolf Magnus schrieb:> Deshalb finde ich es auch gut, daß C++ OOP nicht fest erzwingt, wie es> Java tut. Ähnlich unsinnig finde ich in Java diese Helper-Klassen, die> ausschließlich aus static-Methoden bestehen. Da wurde auch prozedurale> Programmierung in den OOP-Schuh gezwängt. Eine Klasse, die nicht> instanziiert werden soll und von der auch nicht abgeleitet werden soll,> ist für mich irgendwie widersinnig.
Von den meisten Klassen sollte nicht geerbt werden, OOP ist nicht dazu
da ueberall und alles zu vererben, vor allem nicht nur um Code
wiederzuverwenden.
Leute verwechseln gerne Vererbung mit "guter" OOP, das Kernkonzept der
OOP ist immer noch "Daten und Operationen auf diese Daten sollten
zusammensein".
Vererbung bietet sich an, wenn man gemeinsame Schnnittstellen hat und
ausdruecken will "Ist ein", Vererbung hat aber eben den Nachteil der
starken Kopplung, Vererbung zu nutzen nur um Code wiederzuverwenden gilt
als Missbrauch.
Stimme dir zu was die Helper Klassen betrifft, statische Methoden machen
das Mocken schwieriger und zB. in Java schliessen sich static Methoden
und Schnittstellenvererbung aus, fuehrt dann zum sog. "shadowing".
Geeignetes API vorrausgesetzt natürlich. Ist dieser Code unnötig komplex
und lang gegenüber prozeduraler Programmierung? Finde ich nicht.
Hardware-Einheiten wie Pins, USARTS, Timer etc. sind doch in der
Realität Objekte, warum nicht auch in der Programmiersprache als Objekte
darstellen?
Rolf Magnus schrieb:> Deshalb finde ich es auch gut, daß C++ OOP nicht fest erzwingt, wie es> Java tut.
Keine Sprache kann OOP erzwingen. Wenn in in Java alles in eine Klasse
schreibe ist das kein OOP (auch wenn da 1x "class" im Code vorkommt).
Dass Java keine globalen Funktionen&Variablen kann vereinfacht die
Sprache, und Java ist auf Einfachheit ausgelegt. Und mal ehrlich, so
schlimm ist es nicht, einmal "class Blubb {" vor die main() zu
schreiben...
Student schrieb:> Ich programmiere schon seit ein paar Jahren C und wrüde sagen, dass ich> auch ganz gut darin bin. Dieses Semeser habe ich eine C-Lehrveransatung> mit der Höchstunktezahl abgeschlossen
Nach meiner Erfahrung bedeutet das leider nichts. Der Unterricht ist
meistens eher von schlechter Qualität, ob an den Berufsschulen oder an
den Hochschulen. Wenn man Glück hat, hat man einen Dozenten der sich
wirklich auskennt und den Stoff zu vermitteln weiß. Aber das scheint
eher eine Ausnahme zu sein als die Regel (vor allem bei C++). Unser
Professor war ein Microsoftjünger, benutze fflush(stdin) und zwang uns
die ungarische Notation zu benutzen (nach seiner Meinung total
verbreitet. Nur lustig dass Microsoft keine ungarische Notation mehr
benutzt seit der WinAPI ;) ). Achso i++ war natürlich auch noch
schneller als i+=1. Kaum zu glauben, dass er mal in der Wirtschaft tätig
war.
Klaus Wachtler schrieb:> Die schlechte Nachricht:> alles zu C++ lernen = keine Chance, das dauert ewig
Was zum Glück auch nicht sinnvoll ist.
OOP ist wirklich genial und kommt unseren Denken auch sehr viel näher
als reine prozedurale Programmierung. Man sollte allerdings nicht alles
in ein Objekt quetschen nur weil es geht, den Fehler sieht man leider
oft. Java und C# erzwingen das ja quasi (geht sonst nur über statische
Methoden).
TriHexagon schrieb:> Achso i++ war natürlich auch noch> schneller als i+=1. Kaum zu glauben, dass er mal in der Wirtschaft tätig> war.
Als Kellner. Da muß man schnell addieren können.
;-)
MfG Paul
Boris P. schrieb:> Rolf Magnus schrieb:>> Eine Klasse, die nicht instanziiert werden soll und von der auch nicht>> abgeleitet werden soll, ist für mich irgendwie widersinnig.>> Naah, die sind schon sinnvoll. Wenn eine klasse ausschließlich mit> statischen Methoden auskommt, muss sie weder instanziierbar noch> ableitbar sein...
Hast du den Teil davor auch gelesen? Hier ist er nochmal:
Rolf Magnus schrieb:> Ähnlich unsinnig finde ich in Java diese Helper-Klassen, die> ausschließlich aus static-Methoden bestehen. Da wurde auch prozedurale> Programmierung in den OOP-Schuh gezwängt.
Sinnvoll sind sie meines Erachtens nicht, sondern nur eine Notlösung,
weil Java halt keine freistehenden Funktionen unterstützt, man sie aber
eigentlich manchmal doch bräuchte.
Mladen G. schrieb:>> Eine Klasse, die nicht instanziiert werden soll und von der auch nicht>> abgeleitet werden soll, ist für mich irgendwie widersinnig.>> Von den meisten Klassen sollte nicht geerbt werden, OOP ist nicht dazu> da ueberall und alles zu vererben, vor allem nicht nur um Code> wiederzuverwenden.
Das hab ich ja auch nicht behauptet. Aber wenn die Klasse weder
instanziiert, noch von ihr geerbt wird, bleibt gar nichts
objektorientiertes mehr übrig. Ich habe also einen grundlegenden
Bestandteil der OOP - die Klasse - verwendet, um damit etwas umzusetzen,
das mit OOP nichts mehr zu tun hat. Und das ist wie gesagt in meinen
Augen widersinnig.
> Leute verwechseln gerne Vererbung mit "guter" OOP, das Kernkonzept der> OOP ist immer noch "Daten und Operationen auf diese Daten sollten> zusammensein".
Das habe ich ja selbst auch schon geschrieben:
Rolf Magnus schrieb:> Es ist auch möglich, "zuviel OOP" zu machen und sich in nachher niemals> notwenigen Klassenhierarchien zu verkünsteln.
Rolf Magnus schrieb:> Sinnvoll sind sie meines Erachtens nicht, sondern nur eine Notlösung,> weil Java halt keine freistehenden Funktionen unterstützt
Doch, so werden die Methoden sauber gruppiert und sind alle in einem
"Namensraum" (= Name der Klasse) zu finden. Das macht es deutlich
übersichtlicher, als einzelne Funktionen lose im Quellcode
herumschwimmen zu haben...
Außerdem benötigen die Funktionen u.U. auch noch Daten, die hier einfach
als statische Member der Klasse untergebracht werden können. Bei
freischwebenden Funktionen müsste man daraus dann globale Variablen
(ugh!) machen...
Boris P. schrieb:> Rolf Magnus schrieb:>> Sinnvoll sind sie meines Erachtens nicht, sondern nur eine Notlösung,>> weil Java halt keine freistehenden Funktionen unterstützt>> Doch, so werden die Methoden sauber gruppiert und sind alle in einem> "Namensraum" (= Name der Klasse) zu finden. Das macht es deutlich> übersichtlicher, als einzelne Funktionen lose im Quellcode> herumschwimmen zu haben...>> Außerdem benötigen die Funktionen u.U. auch noch Daten, die hier einfach> als statische Member der Klasse untergebracht werden können. Bei> freischwebenden Funktionen müsste man daraus dann globale Variablen> (ugh!) machen...
Danke dafür, dass Du meine Antwort geschrieben hast. Genau so sollte sie
aussehen ;-)
Ein Namespace ist schon ganz angenehm, eben weil da die Variablen nicht
einfach auf der globalen Ebene "rumfliegen".
Grundsätzlich ist OOP wohl intuitiver, allerdings nicht für Leute, die
durch prozedurale Programmierung schon "verdorben" sind.
Ich habe mich damals auch erst schwer getan, das Konzept zu verstehen.
Aber danach ist es eigentlich die logische Abbildung von realen
Problemen.
Student schrieb:> Bevor ich mich> dazu anmelde wollte ich mir noch kurz euere Meinungen hohlen, wie> schwierig ihr es einschätzt C++ noch dazuzulernen.
Schwierig nicht, aber man steht plötzlich vor vielen Fragen der
SW-Architektur, die man ohne OOP nie gestellt hätte. Das zeigt auch die
Diskussion, die hier gerade (wieder!) entbrennt.
Nun lasst doch erstmal 'Student (Gast)' zu Wort kommen!
'Diskussionen zum Sebstzweck' haben wir im
Beitrag "C++ auf einem MC, wie geht das?"Klaus Wachtler schrieb:> Ab einer gewissen Komplexität hast du aber natürlich recht, aber das ist> nicht Mobys Welt.
Ach, geht das hier jetzt auch los? ;-) Der arme 'Student (Gast)' wird
viel Stoff zum Lesen bekommen!
Boris P. schrieb:> Doch, so werden die Methoden sauber gruppiert und sind alle in einem> "Namensraum" (= Name der Klasse) zu finden. Das macht es deutlich> übersichtlicher, als einzelne Funktionen lose im Quellcode> herumschwimmen zu haben...>> Außerdem benötigen die Funktionen u.U. auch noch Daten, die hier einfach> als statische Member der Klasse untergebracht werden können. Bei> freischwebenden Funktionen müsste man daraus dann globale Variablen> (ugh!) machen...Chris D. schrieb:> Danke dafür, dass Du meine Antwort geschrieben hast. Genau so sollte sie> aussehen ;-)
Ich habe auch erst anfangen wollen, einen änlichen Text zu schreiben,
aber bei genauerem Überlegen dann auch festgestellt, dass er recht hat.
Die Funktionen/Member würden sich ja ohnehin im Namensraum des Packages
befinden (im weitesten Sinne das, was bei c++ die Namespaces sind). Sie
würden also keineswegs wie bei C den globalen Namensraum verschmutzen.
Edit:
Bei C++ ist eine Klasse mit nur statischen Methoden ja quasi äquivalent
zum einem Namensraum, hat aber den Nachteil, dass man nix "von außen"
hinzufügen kann.
Boris P. schrieb:> Rolf Magnus schrieb:>> Sinnvoll sind sie meines Erachtens nicht, sondern nur eine Notlösung,>> weil Java halt keine freistehenden Funktionen unterstützt>> Doch, so werden die Methoden sauber gruppiert und sind alle in einem> "Namensraum" (= Name der Klasse) zu finden.
Dazu gibt es (zumindset in C++) Namespaces. Man muss dafür nicht extra
eine ansonsten nutzlose Klasse anlegen.
> Außerdem benötigen die Funktionen u.U. auch noch Daten, die hier einfach> als statische Member der Klasse untergebracht werden können. Bei> freischwebenden Funktionen müsste man daraus dann globale Variablen> (ugh!) machen...
Wo ist denn deiner Meinung nach der große Unterschied zu einer globalen
Variable?
Ich hab schon häufig gesehen, daß irgendwelche merkwürdigen Verrenkungen
gemacht werden, um globale Variablen durch was zu ersetzen, das auch
nicht besser ist, aber offiziell dann nicht mehr als globale Variable
gilt.
So wie z.B. der Mißbrauch von Singletons, der in dem Zusammenhang auch
oft begangen wird.
Mladen G. schrieb:> Leute verwechseln gerne Vererbung mit "guter" OOP, das Kernkonzept der> OOP ist immer noch "Daten und Operationen auf diese Daten sollten> zusammensein".
Nein. Da war nie "das Konzept" von OOP.
Eine verbreitete Strömung der OOP-Sprachen hat diesen (einschränkenden)
Weg gewählt.
Andere OOP-Sprachen trennen Daten und Methoden strikt. Ein Beispiel wäre
Common Lisp. Gibt noch andere.
Rolf Magnus schrieb:> Wo ist denn deiner Meinung nach der große Unterschied zu einer globalen> Variable?
Dass die Variable nur innerhalb der Klasse sichtbar ist. Somit kann ich
sicher sein, dass diese nicht von anderen Stellen aus verwendet werden
kann.
Boris P. schrieb:> Dass die Variable nur innerhalb der Klasse sichtbar ist. Somit kann ich> sicher sein, dass diese nicht von anderen Stellen aus verwendet werden> kann.
wenn ich das nicht will, kann ich sie genauso gut statisch im c/cpp file
definieren und muss sie nicht im Header als extern exportieren.
Marc schrieb:> Mladen G. schrieb:>> Leute verwechseln gerne Vererbung mit "guter" OOP, das Kernkonzept der>> OOP ist immer noch "Daten und Operationen auf diese Daten sollten>> zusammensein".>> Nein. Da war nie "das Konzept" von OOP.>> Eine verbreitete Strömung der OOP-Sprachen hat diesen (einschränkenden)> Weg gewählt.>> Andere OOP-Sprachen trennen Daten und Methoden strikt. Ein Beispiel wäre> Common Lisp. Gibt noch andere.
Falsch. (um mal auf demselben Niveau zu antworten..)
Common Lisp hat auch Elemente von funktionalen Programmiersprachen, und
dazu gehoert u.a. die Trennung von Daten und Funktionen.
OOP basiert darauf Daten und die Operationen die auf diesen Daten
arbeiten in Objekte zu kapseln, sollte man eigentlich im OOP
Grundlagenkurs gelernt haben.
Vererbung, wenn richtig eingesetzt
(http://en.wikipedia.org/wiki/Liskov_substitution_principle), kommt viel
seltener zum Einsatz als viele glauben.
Mladen G. schrieb:> Falsch. (um mal auf demselben Niveau zu antworten..)
Informier dich doch erstmal.
> Common Lisp hat auch Elemente von funktionalen Programmiersprachen, und> dazu gehoert u.a. die Trennung von Daten und Funktionen.
Das Common Lisp Object System (CLOS) ist Objektorientierung.
Im übrigen könntest du dich auch mal über generic functions oder auch
multiple dispatch schlaumachen.
Die Verquickung von Daten und Methoden führt nämlich direkt zu single
dispatch, nämlich einem ausgezeichneten, "führenden" Objekt beim
Dispatch: üblicherweise this genannt.
Und daher kommen dann auch Verrenkungen wie friend in C++.
Vlad Tepesch schrieb:> wenn ich das nicht will, kann ich sie genauso gut statisch im c/cpp file> definieren und muss sie nicht im Header als extern exportieren.
Joar, kann man so machen. Wenn man's mag ;-)
Dr. Sommer schrieb:> Klaus Wachtler schrieb:>> Das langwierigste ist sicher, die OO-Denkweise zu verinnerlichen> Als ob, das ist noch schön einfach und leicht vorstellbar. Warum immer> alle Angst vor OOP haben verstehe ich nicht.
Man kann schon ganz schön lange über Probleme nachdenken, die man ohne
OOP gar nicht gehabt hätte. Allein schon das Beispiel 'Ist ein Kreis
etwa keine Ellipse'^^ zeigt, vor welchen Entscheidungen man hier steht.
Und bei C++11 wird´s noch schlimmer!
> * Fehlschlagspezifikation für die Größenanpassung> * Vertauschen der Vererbungsrichtung> * Verzicht auf eine Spezialisierung> * Verzicht auf eine Vererbungsbeziehung> * Erweiterung der Vererbungshierarchie> * ...
Bücher wurden ja schon empfohlen. Man sollte sich verschiedene Typische
Patterns anschauen ("Entwurfsmuster" unter Wikipedia), bevor man mit der
Einstellung "das ist … einfach und leicht vorstellbar"^^ anfängt und
merkt, dass man auf dem Holzweg war, wenn man eigentlich mit der SW
schon fertig sein wollte.
Wer kennt das? Wem ist das noch nie passiert?
BTW: Nachdem wir im anderen Thread bereits Peter Dannegger 'verloren'
haben, hängen wir hier auch gerade den OP 'Student (Gast)' ab. Oder?
@Student: Sag doch mal was!
Konnten wir Dir helfen? Hast Du Dich schon entschieden?
Torsten C. schrieb:> Man kann schon ganz schön lange über Probleme nachdenken, die man ohne> OOP gar nicht gehabt hätte.
die gleichen Probleme stellen sich bei klassischer imperativer
programmierung aber genauso.
MAn hat ein Haufen komplexer Anforderungen, die nicht trivial zu lösen
sind und muss irgendwie einkomplexes System Programmieren, dessen
EInzelteile dennoch ÜBerschaubar sind und das am besten noch mit einer
Feinen Gui gesteuert werden kann.
Hier hat sich der objektorientierte Ansatz nunmal am besten bewährt.
Während darüer diskutiert wird, welche Entwurfsmuster zur Abbildung am
besten geeignet sind, stellt sich die Frage in C meistens nicht, weil
man hier immer noch damit beschäftigt ist die Basisfunktionalität, die
C++ schon mitbringt zusammenzuschustern und froh ist, wenn die erst msl
läuft und dann den den Rest aufgrund von Zeitmangel irgendwie
reinfummelt.
