Archiv verlassen und diese Seite im Standarddesign anzeigen : OOP schlecht zum Anfangen
Ich habe in der Uni genug Umgang mit absoluten Programmieranfängern und denen braucht man nicht mit OOP kommen. Beziehungsweise man tut ihnen damit keinen Gefallen. Gerade Programmierer verkennen völlig die gedankliche Komplexität von OOP-Ansätzen. Mit "natürlich" und "einfach" ist da nicht wirklich viel. Um's mal auf den Punkt zu bringen, Java überfordert erst mal alle Anfänger und auch nach einem Semester intensiven lernens kriegen es sehr viele nicht gebacken vernünftige Programme in Java zu schreiben. Werden die Leute aber mit z.B. Perl als erstes konfrontiert, verstehen sie es ziemlich schnell und schreiben auch brauchbare Skripte damit. Und Perl ist sicherlich nicht die Sprache mit der "schönsten" Syntax. Aber man programmiert damit meistens prozedural und hinter diesem Paradigma steckt wenig dahinter. Der Gegensatz dazu ist OOP mit sehr viel Konzepten, die dahinter stehen und die Komplexität entsprechend hochtreiben. Herrje, selbst abgefahrene Sachen wie Prolog fällt den Anfängern hier leichter.
Objekt-orientierte Systeme sind zum Bauen größerer Anwendungen eine absolute Wohltat und vergleichsweise geradezu ein Traum, aber sie sind auch komplex. Dagegen will "man" keine großen Anwendungen prozedural bauen, aber das Konzept dahinter ist furchtbar primitiv und einfach zu verstehen.
Sicher, wenn man frei weg von der Leber philosophiert sieht man viel WinAPI-Code und wenig OOP-Framework-Code und ist deswegen versucht ersteres als höllisch schwer und letzteres als furchtbar einfach zu sehen. Die Anfänger-Praxis sieht aber eben anders aus.
Aha. Und was möchtest du uns damit sagen?
anderer Gast
2006-11-19, 20:04:35
Hm ich weiß ja nicht, aber wenn man an einer Uni studiert sollte man imho in der Lage sein sich OOP auch selbst anzueignen. Zudem ist OOP doch gar nicht so abgehoben, weil man aus der normalen Sichtweise heraus Sachverhalte doch meist als Zusammenhänge und Interaktionen zwischen Objekten sieht.
Um was für Studiengänge geht es dir denn überhaupt?
ethrandil
2006-11-19, 21:22:14
Ja und nein, wenn man mich fragt.
Das Programmieren mit OOP kann man sich selber beibringen. Objektorientierte Architektur und Design wird jedoch schwierig :)
- eth
Kabelsalat
2006-11-19, 21:33:52
Ja und nein, wenn man mich fragt.
Das Programmieren mit OOP kann man sich selber beibringen. Objektorientierte Architektur und Design wird jedoch schwierig :)
- eth
Ich finde jedoch, dass man gerade das sehr gut selber lernen kann: Aus Interesse beschäftige ich mich häufig mit "fertigen" Anwendungen bzw. deren Quellcode. Gerade in Bezug auf das Design kann man dabei viel lernen, aber auch ansonsten ist das eine sehr beeindruckende Sache... spannend ist dabei eigentlich alles von der eher kleinen Anwendung bis zu ganz großen Brocken wie etwa der SSCLI (Rotor) oder Mono.
ethrandil
2006-11-19, 21:44:06
Ich finde jedoch, dass man gerade das sehr gut selber lernen kann: Aus Interesse beschäftige ich mich häufig mit "fertigen" Anwendungen bzw. deren Quellcode. Gerade in Bezug auf das Design kann man dabei viel lernen, aber auch ansonsten ist das eine sehr beeindruckende Sache... spannend ist dabei eigentlich alles von der eher kleinen Anwendung bis zu ganz großen Brocken wie etwa der SSCLI (Rotor) oder Mono.Da siehst du mal - das tue ich zum Beispiel nicht.
Ich dneke eine derart intensive Beschäftigung kann man einem Informatikstudenten kaum zumuten - schließlich will gar nicht jeder in diese Richtung gehen (ich).
Prinzipiell kann man sich einfach alles selber beibringen - ein Telefon, Internet und einen Bibliotheksausweis vorausgesetzt.
- eth
wofür brauch man das telefon?
Das hab ich mich auch gerade gefragt :)
ethrandil
2006-11-19, 23:00:50
Na dann will ich es mal auflösen: Damit man Autoren oder Kollegen anrufen kann, wenn man fragen hat.
Da hätte jetzt wohl keiner mit gerechnet, was? Back to Topic?
mfg
- eth
The_Invisible
2006-11-19, 23:07:22
kommt halt auch auf die sprache an finde ich.
mit java wird einem nix anderes übrigbleiben als sich mit OOP auseinanderzusetzen, dann gibts zb python was auch sehr objektorientiert ausgelegt ist aber man auch prozedural programmieren kann und zum schluß dann eben C.
wenn man wirklich frisch anfängt sollte man imho um OOP zunächst nen größeren bogen machen, am anfang ist man schon froh wenn man weiß was ne "function" ist und kann.
mfg
ScottManDeath
2006-11-19, 23:52:14
wofür brauch man das telefon?
Frust 0190 anyone :biggrin:
Wir hatten damals an der FH ein Semester prozedural in C, dann ein Semester Datenstrukturen und Algorithmen, war so C/C++, dann ein Semester Objekt orientiert in C++ und ein Semester deklarativ LISP und Prolog. Yuck :confused:
In den Vorlesungen lern man eh nur solange rumzutippen bis die Compilerfehler weg sind, von Warnungen gar nicht zu reden. :(
Programmieren lernt man nur durch Quellcode lesen und Quellcode schreiben.
Damals als ich anfing zu lernen, gabs noch kein Internet :|
wenn man wirklich frisch anfängt sollte man imho um OOP zunächst nen größeren bogen machen, am anfang ist man schon froh wenn man weiß was ne "function" ist und kann.
mfg
Das eh, aber das heißt ja nicht zwangsweise, dass es nicht Java sein muss. Funktionen, eben prozedurale Programmierung, einfache arithmetische Operationen und was man halt alles am Anfang lernt kann man ja in jeder Sprache machen, wieso als nicht auch Java? Das Klassengerüst und alle OOP Teile kann man zunächst ja außen vor lassen. Deshalb ist Java ja nicht weniger geeignet als andere Sprachen, allerdings würd ich mich an eine Sprache mit C-ähnlicher Syntax halten.
Prinzipiell stimme ich aber zu der allgemeinen Thematik zu, dass man sich mit OOP erst im späteren Verlauf beschäftigen sollte.
Ich stimme dem Threadersteller voll und ganz zu.
Ich selbst habe mein Programmieren mit prozeduralen Programmiersprachen und der Prozeduralen Programmierung angefangen und finde sie sau einfach, aber die Objekt Orientierte Programmierung finde ich, wenn man nicht in eine Prozedurale Programmierung mit OO Sprachen zurückfallen will, sau schwierig.
Die Grundprinzipien Objekte, Methoden und Datenkapselung ist ja noch alles ganz einfach, aber erstmal den Dreh rauszubekommen, wie die Objekte miteinander interagieren sollen und wie man ein Programm vom Konzept zum Design und dann zur Implementierung durchplant ist sau schwer, erst recht, wenn man in der OOP noch kaum Ahnung hat.
Daher habe ich eine Frage an euch.
Ich brauche unbedingt ein sehr gutes Buch, daß einem die Objekt orientiere Programmierung beibringt, so daß es am Ende auch Klick macht.
Das habe ich heute nämlich noch immer nicht ganz rausgekriegt.
Und dann würde mich noch interessieren, wie man das Model View Controller Modell mit der Objekt Orientierten Progammierung verbinden.
Auch das ist sau schwierig.
man ist ja nicht gezwungen oo zu programmieren, auch bei java nicht, oder?
dennoch läufts bei den höheren programmiersprachen oft immer wieder auf den aufruf von irgendwelchen funktionen und methoden hinaus.
manche brauchen das vielleicht auch gar nicht - ein kollege von mir hats nie gelernt, und mit dem bisschen was er braucht kommt er prozedural zurecht.
was das lernen betrifft: siehe online anfänger tutorials. da kommt oop in einem java anfänger kurs schon in kapitel 5 von 30.
AtTheDriveIn
2006-11-20, 02:53:51
Daher habe ich eine Frage an euch.
Ich brauche unbedingt ein sehr gutes Buch, daß einem die Objekt orientiere Programmierung beibringt, so daß es am Ende auch Klick macht.
Ich hatte zu Beginn meiner C++ Zeit ein Buch mit dem Titel "C++ in 21 Tagen" von Jesse Liberty. Imo eines der besten C++/OOP Einsteigerbücher überhaupt.
man ist ja nicht gezwungen oo zu programmieren, auch bei java nicht, oder?
Wenn man das Zeug mal studieren will, dann schon.
Monger
2006-11-20, 08:51:54
Meine Theorie ist ja, dass vorallem den Leuten OOP so schwer fällt, die vorher was prozedurales gemacht haben, weil es zwar ähnlich aussieht, aber ein VÖLLIG anderer Ansatz ist. Zumindest ging es mir so.
Mein Argument hier ist: kein Mensch will nur "Hello World" Programme schreiben. Jetzt mal von ganz billigen Skripten abgesehen gibt es keine einfache Software. Der Sinn von Software ist ja nunmal auch, Dinge zu tun zu denen der Mensch nicht mehr in der selben Weise in der Lage ist, und dementsprechend wird Software ab einer gewissen Komplexitätsstufe erst so richtig interessant.
OOP-lastige Sprachen wie Java haben den Nachteil, dass so 20-Zeiler bei ihnen unnötig klobig sind. Wer in Java sein erstes Hello World Programm schreibt, wird erstmal mit lauter Sonderfällen erschlagen: eine statische Methode, ein Konsolenprint, wenn man das ganze ausführen und packen will auch noch eine Manifest Datei...
Sobald man aber ein bißchen mehr macht, sind sie VIEL einfacher zu bearbeiten, weil man jede Klasse, jede Methode gesondert betrachten kann.
Bei prozeduralen Sprachen (auch Mischsprachen) ist es genau umgekehrt: erst wirkt alles ganz simpel, und dann fangen die Probleme erst so richtig an, bis sie sich in ungeahnte Höhen auftürmen.
Deshalb: wenn man die ersten zehn Stunden OOP überstanden hat, wird es imho RELATIV simpel. Wirklich einfach wird es natürlich nie, aber der Schwierigkeitsgrad hält an, statt zu explodieren. Deshalb: prozedurale Sprachen geben einem eine trügerische Sicherheit, aber in Wahrheit sind sie VIEL komplizierter zu handhaben.
AtTheDriveIn
2006-11-20, 11:38:08
Deshalb: wenn man die ersten zehn Stunden OOP überstanden hat, wird es imho RELATIV simpel. Wirklich einfach wird es natürlich nie, aber der Schwierigkeitsgrad hält an, statt zu explodieren. Deshalb: prozedurale Sprachen geben einem eine trügerische Sicherheit, aber in Wahrheit sind sie VIEL komplizierter zu handhaben.
Sehe ich auch so. Allerdings halte ich 10 Stunden für sehr optimistisch ;)
Die OOP wurde ja genau aus dem Grunde eingeführt das man große Aufgaben überhaupt handlen kann. An die Natur angelehnte Entwicklung mit Objekten, Vererbung, nach außen definierten Schnittstellen... all das finden wir auch unserer Umwelt wieder.
Ich muß als Taxifahrer nicht wissen wie ein Auto intern funktioniert oder es erfinden, sondern nur wissen was ich wie damit machen kann.
man ist ja nicht gezwungen oo zu programmieren, auch bei java nicht, oder?
was das lernen betrifft: siehe online anfänger tutorials. da kommt oop in einem java anfänger kurs schon in kapitel 5 von 30.
Nein man ist bei kleinen Anfängerprogrammen nicht gezwungen OOP zu verwenden. Wie ich gesagt habe, für wirkliches Basis-Programmierwissen reicht meistens eine Mainmethode und ein paar kleinere Methoden aus. zB für kleine Rechenprogramme und Ähnliches. Anfangs wird man ja hauptsächlich mit Programmierlogik, Operatoren, Datentypen, Funktionen usw. beschäftigt sein.
Aber da in Java ja quasi alles ein Objekt ist, ist es nur verständlich dass OOP so früh kommt, weil man ja sonst nicht weitermachen kann. Alles darauffolgende baut ja auf Objekten auf und wie will man das sonst verstehen?
mit java wird einem nix anderes übrigbleiben als sich mit OOP auseinanderzusetzen, oder man macht es so, wie ich es jahrelang mit Delphi gemacht habe:
man nimmt einfach die von der Sprache vorgegebene Notwendigkeit, eine umschließende Klasse zu deklarieren, mit einem "ahja, soso" zur Kenntnis und kümmert sich dann nicht weiter darum, sondern macht einfach munter weiter prozedurale Programmierung. In Delphi, indem man TForm1.Button1Click als Hauptprogramm mißbraucht, von dem aus man konventionelle Prozeduren/Funktionen aufruft, in Java, indem man die aufgerufenen Funktionen einfach zu Methoden der umschließenden Dummy-Klasse macht und eventuell anfallende globale Variablen zu Datenmembern. Der einzige Unterschied zu einem Programm in einer prozeduralen Sprache wie C ist dann das class XY{ am Anfang und das zugehörige schließende } am Ende. Das beim Programmierer noch weniger Aufmerksamkeit auf sich zieht als ein extern "C" in irgendeinem tief verschachtelten Header eines C++ Programms.
Leute zur OOP erziehen kann man auf diese Weise nicht.
Ich muß dem Threadersteller zustimmen, daß OOP für Programmieranfänger denkbar ungeeignet ist. Wenn man den Leuten das Programmieren in imperativen Sprachen beibringt, sollte man mit einfacher Programmierung anfangen, dann Prozeduren und Funktionen einführen, und dann erst zur OO übergehen, und zwar praktisch und theoretisch zugleich. Und die erste OOP-Aufgabe sollte dann schon explizit die Anforderung nach mehreren Klassen enthalten (2 oder 3 reichen für den Anfang, es sollte aber auf jeden Fall nicht nur eine einzige sein).
Das alles sollte man in einer Sprache tun, die OOP zwar unterstützt, aber nicht erfordert, z.B. C++. Erst danach kann man dann zu Sprachen übergehen, die entweder nur OOP erlauben (Java, C#), oder zwangsläufig OOP-Elemente enthalten (Delphi).
Meine Theorie ist ja, dass vorallem den Leuten OOP so schwer fällt, die vorher was prozedurales gemacht haben, weil es zwar ähnlich aussieht, aber ein VÖLLIG anderer Ansatz ist. Zumindest ging es mir so.wo das ein völlig anderer Ansatz ist, mußt du mir aber erstmal erklären. Soweit ich seit meinem Einstieg in die OOP sehe - und worin ich seither auch durch nichts widerlegt wurde - hat OOP in erster Linie die Aufgabe, eine Ordnungsstruktur oberhalb der Ebene der Funktionen und Prozeduren zu etablieren, sprich: Prozeduren thematisch zu ordnen, indem man diejenigen unter ihnen, die für eine bestimmte Kollektion von Daten relevant sind, zu Methoden einer einzigen Klasse macht und dabei zugleich ebenjene Kollektion von Daten, die sonst ein wild wucherndes Dasein als lokale Variablen, Parameter und Rückgabewerte fristen würden, in Form von Datenmembern in dieses Ordnungskonstrukt mit einbezieht.
Ich hatte zu Beginn meiner C++ Zeit ein Buch mit dem Titel "C++ in 21 Tagen" von Jesse Liberty. Imo eines der besten C++/OOP Einsteigerbücher überhaupt.
Ich werde mal einen Blick drauf werfen.
Aber das ist ein Eintseigerbuch, richtig?
Gibt es auch ein Buch für Umsteiger mit schon vorhandener Erfahrung für Prozedurale Programmierung?
So etwas würde ich noch besser finden, also ein Buch, das sich auf die OOP spezialisiert hat.
Den ein Buch in dem die ganz normalen Grundlagen wie Schleifen und Co erwähnt werden,
die ich aus der prozeduralen Programmierung sowieso schon kenne, brauche ich nicht.
Monger
2006-11-20, 17:06:08
wo das ein völlig anderer Ansatz ist, mußt du mir aber erstmal erklären. Soweit ich seit meinem Einstieg in die OOP sehe - und worin ich seither auch durch nichts widerlegt wurde - hat OOP in erster Linie die Aufgabe, eine Ordnungsstruktur oberhalb der Ebene der Funktionen und Prozeduren zu etablieren, sprich: Prozeduren thematisch zu ordnen, indem man diejenigen unter ihnen, die für eine bestimmte Kollektion von Daten relevant sind, zu Methoden einer einzigen Klasse macht und dabei zugleich ebenjene Kollektion von Daten, die sonst ein wild wucherndes Dasein als lokale Variablen, Parameter und Rückgabewerte fristen würden, in Form von Datenmembern in dieses Ordnungskonstrukt mit einbezieht.
OOP zeichnet sich durch mehr als nur einen eindeutigen Namespace aus. Du betrachtest das auch von der falschen Richtung aus: Methoden werden nicht zu Klassen gruppiert, sondern Klassen sind zuerst da, und die Klassendefinitionen machen dann bestimmte Methoden notwendig. Anders kannst du überhaupt keinen vernünftigen Top-Down Ansatz machen.
Aber es gibt noch viel wichtigeres. In den klassischen prozeduralen Sprachen gibt es eine hierarchische Lebensdauer, d.h. : wenn die Hauptmethode durchgelaufen ist, ist auch das Programm beendet. Das trifft für OOP Sprachen halt überhaupt gar nicht zu.
Schon alleine Multithreading ist prozedural gar nicht machbar. Oder wie sieht ein Thread in C aus?
Schon alleine Multithreading ist prozedural gar nicht machbar. Oder wie sieht ein Thread in C aus?so ein quatsch
Schon alleine Multithreading ist prozedural gar nicht machbar. Oder wie sieht ein Thread in C aus?
Das tut weh Monger...
MikeB
2006-11-20, 19:31:46
Das tut weh Monger...
Jetzt untertreibst du aber masslos ! :D
Mehr ein pädagogisches Problem. Der Ansatz "OOP ist prozedurale Programmierung plus das und das und das" ist wohl nicht der beste.
http://www.squeakersfilm.org
OOP zeichnet sich durch mehr als nur einen eindeutigen Namespace aus. Du betrachtest das auch von der falschen Richtung aus: Methoden werden nicht zu Klassen gruppiert, sondern Klassen sind zuerst da, und die Klassendefinitionen machen dann bestimmte Methoden notwendig. das widerspricht nicht dem was ich geschrieben habe. Stell dir vor, du hast die schlechte Angewohnheit, einfach drauf loszuprogrammieren statt vorher ein sauberes Softwaredesign zu machen. Bei prozeduraler Programmierung bekommst du so sehr schnell einen Wildwuchs an Prozeduren. Das Klassenkonstrukt kannst du dann als Hilfsmittel für einen notdürftigen Design-Ersatz heranziehen: statt beim drauf los programmieren mit einer Prozedur anzufangen, startest du mit einer Klasse. Und legst damit eine Kategorie von thematisch zusammenfaßbaren, noch zu ersinnenden Prozeduren fest. Was dir ebenjenes Ersinnen von Prozeduren erleichtert.
Aber es gibt noch viel wichtigeres. In den klassischen prozeduralen Sprachen gibt es eine hierarchische Lebensdauer, d.h. : wenn die Hauptmethode durchgelaufen ist, ist auch das Programm beendet. ist in OO-Sprachen auch so. In Delphi endet das Programm mit dem Ende von TApplication.Run, in .NET mit dem Ende von Application.Run. In Java mit dem Ende von public static void main().
Schon alleine Multithreading ist prozedural gar nicht machbar. Oder wie sieht ein Thread in C aus?
// Funktion die im Thread läuft
void ThreadProc(void* pParam)
{
//...
}
//...
// starten des Threads
HANDLE hThread = _beginthread(ThreadProc, 0, NULL);
ist in OO-Sprachen auch so. In Delphi endet das Programm mit dem Ende von TApplication.Run, in .NET mit dem Ende von Application.Run. In Java mit dem Ende von public static void main().
Eigentlich ist es in .NET auch eine main()-Funktion (und in Delphi wohl auch). Wie die in den einzelnen Sprachen heißt ist ja was anderes.
derRäuber
2006-11-22, 20:21:53
Ich finde auch dass es absolut falsch ist mit OOP anzufangen.
Diejenigen, die noch nie umfangreichere Programme geschrieben haben, können garnicht verstehen was all die Konzepte von OOP auf sich haben und warum man sie überhaupt anwendet.
Es ist eben gerade wichtig die Fehler mit einfachen Funktionsorientierten Sprachen zu machen um zu verstehen dass man (wenn angebracht) konzeptionell umdenken sollte.
Zudem ist es meiner Meinung total logisch dass man etwas viel besser lernt, wenn die Abstraktion mit der Zeit zunimmt. Und nicht umgekehrt!
Das ist wirklich eine enorme Fehlentwicklung.
Gutes Beispiel sind die vielen XML-Fanatiker, die wenn man nachfragt, garnicht konsequent bis zum Ende darüber nachgedacht haben warum sie überhaupt verfallen sind.
Wenn überall etwas abstraktes gepredigt wird, dies dann noch einen hippen Namen hat, wenden es viele oft falsch an, da sie garnicht den Sinn (oder Unsinn) dahinter verstehen.
ethrandil
2006-11-22, 23:30:12
Unsere Profs bringen im ersten Semester nur Funktionen, Objekte und Interfaces (Java) bei. Im zweiten erst kommen Gernerizität und Vererbung.
Wie findet ihr das?
mfg
- eth
Unsere Profs bringen im ersten Semester nur Funktionen, Objekte und Interfaces (Java) bei. Im zweiten erst kommen Gernerizität und Vererbung.
Wie findet ihr das?1) ich denke so kann man das durchaus machen. OOP ist schon ohne Vererbung ein hinreichend komplexes Thema, da kann man die Vererbung ruhig erst später durchnehmen. Ich persönlich habe meine ersten OO Programme auch erst ohne Verwendung von Vererbung geschrieben.
2) was meinst du in diesem Zusammenhang mit Interfaces? Die Gesamtheit der public-Member einer Klasse? Oder ein Interface, das die Klasse implementiert? Letzteres kann es ja eigentlich nicht sein, da es schon zu viel mit Vererbung zu tun hat, und ich weiß auch nicht ob's das bei Java überhaupt gibt oder nur in .NET...
3) was ist das eigentlich für ein Studium, wo einem die Profs so was beibringen? Nachdem was ich gehört habe, macht man so etwas in Informatik z.B. nicht (kann's natürlich nicht selbst beurteilen, hab kein Informatik studiert). Vielleicht Informatik FH?
ethrandil
2006-11-23, 01:39:34
2) was meinst du in diesem Zusammenhang mit Interfaces? Die Gesamtheit der public-Member einer Klasse? Oder ein Interface, das die Klasse implementiert? Letzteres kann es ja eigentlich nicht sein, da es schon zu viel mit Vererbung zu tun hat, und ich weiß auch nicht ob's das bei Java überhaupt gibt oder nur in .NET...
3) was ist das eigentlich für ein Studium, wo einem die Profs so was beibringen? Nachdem was ich gehört habe, macht man so etwas in Informatik z.B. nicht (kann's natürlich nicht selbst beurteilen, hab kein Informatik studiert). Vielleicht Informatik FH?
zu 2) Ich meine ein Interface, dass eine Klasse implementiert. Das hat zwar wirklich mit Vererbung zu tun, aber nur mit Klassifizierung und Typhierarchien. Nicht mit Vererbungshierarchien. Ist insofern nicht ganz so sehr vereinfacht, wie man denken könnte.
3) Gemacht wurde das im Bachelor-Studiengang Informatik einer Universität in der Vorlesung 'Objektorientierte Softwareprogrammierung und Modellierung'. Es geht an der Uni natürlich ein bisschen abstrakter um Typhierarchien, etc. Allerdings war die Klausur für jemanden der Java beherschte nicht wirklich schwer.
mfg
- eth
derRäuber
2006-11-23, 10:16:06
Unsere Profs bringen im ersten Semester nur Funktionen, Objekte und Interfaces (Java) bei. Im zweiten erst kommen Gernerizität und Vererbung.
Wie findet ihr das?Auch nicht viel besser.
Man wendet dabei Dinge wie Garbagecollection, komplexe Typkonvertierung usw. an, ohne wirklich zu verstehen warum es dies überhaupt gibt und was dahinter steckt.
Register -> Zeiger -> Objektreferenzen -> Templates -> Graphen usw.
So sollte der Lernprozess z.B. von Datentypen über die Jahre aussehen.
Man wendet dabei Dinge wie Garbagecollection, komplexe Typkonvertierung usw. an, ohne wirklich zu verstehen warum es dies überhaupt gibt und was dahinter steckt.
Register -> Zeiger -> Objektreferenzen -> Templates -> Graphen usw.
Register als unterste Ebene zu wählen ist völlig willkürlich. Warum bei Registern aufhören? Drunter gibts noch Gatter, Transistoren, Elektrotechnik, Halbleiterphysik und Quantenphysik.
Es geht in den Einführungsveranstaltungen zur Programmierung darum Leuten beizubringen, was eine Programmiersprache ist und wie man sie verwendet. Nicht darum wie man eine Programmiersprache implementiert oder Performanceoptimierungen durchführt. Register und Zeiger nehmen nur Zeit weg, die man sonst für ausführlichere Erklärungen zum eigentlichen Thema der Veranstaltung nutzen könnte.
Das Wichtigste an jeder Erklärung ist die Auswahl der Dinge die man weglässt.
Die meisten Einführungen, die ich gelesen oder gesehen habe, lassen weg wie man die Programmiersprache benutzt und erklären ausführlich wie sie aufgebaut ist. Diese Aufteilung halte ich für ungeschickt, aber offensichtlich ist das eine Minderheitenmeinung. Vielleicht liegt das daran, dass man Faktenwissen einfacher abfragen kann als Verständnis darüber, wie man etwas benutzt.
In OOP-Veranstaltungen ist das oft deutlich ausgeprägter, man will ja kein feature ungenannt lassen und für den Rest bleibt dann halt keine Zeit mehr.
Register als unterste Ebene zu wählen ist völlig willkürlich. Warum bei Registern aufhören?
Weil das die letzte Ebene ist wo man als Programmierer noch Zugriff darauf hat.
Monger
2006-11-23, 13:56:30
Das Wichtigste an jeder Erklärung ist die Auswahl der Dinge die man weglässt.
Die meisten Einführungen, die ich gelesen oder gesehen habe, lassen weg wie man die Programmiersprache benutzt und erklären ausführlich wie sie aufgebaut ist. Diese Aufteilung halte ich für ungeschickt, aber offensichtlich ist das eine Minderheitenmeinung. Vielleicht liegt das daran, dass man Faktenwissen einfacher abfragen kann als Verständnis darüber, wie man etwas benutzt.
In OOP-Veranstaltungen ist das oft deutlich ausgeprägter, man will ja kein feature ungenannt lassen und für den Rest bleibt dann halt keine Zeit mehr.
Ich bin völlig deiner Meinung. Einem Flugzeugpiloten sollte man nicht erklären wie Düsentriebwerke gebaut werden, sondern umso mehr wie er damit umgehen soll.
Auch programmieren lernt man ja nicht des programmierens willen, sondern weil man etwas bestimmtes erreichen will. Wozu sich mit dem Kleinkrams abgeben? Soll sich doch die Maschine mit dem Mist rumschlagen.
Wenn ich einen Compiler oder ein Betriebssystem entwickeln will, reicht mir das Wissen natürlich nicht. Aber dann brauche ich ohnehin noch mindestens eine weitere Vorlesung - in ein paar Sätzen sind solche Themen nicht abgehandelt.
derRäuber
2006-11-23, 14:07:36
Register als unterste Ebene zu wählen ist völlig willkürlich. Warum bei Registern aufhören? Drunter gibts noch Gatter, Transistoren, Elektrotechnik, Halbleiterphysik und Quantenphysik.Nö. Bei der technischen Informatik sollte man mit Elektrotechnik anfangen, und bei der praktischen mit Rechnerarchitektur.
Das ist nicht willkürlich, sondern das Basisfundament für alle Anwendungen im Fachgebiet.
Es geht in den Einführungsveranstaltungen zur Programmierung darum Leuten beizubringen, was eine Programmiersprache ist und wie man sie verwendet. Nicht darum wie man eine Programmiersprache implementiert oder Performanceoptimierungen durchführt. Register und Zeiger nehmen nur Zeit weg, die man sonst für ausführlichere Erklärungen zum eigentlichen Thema der Veranstaltung nutzen könnte.
Das Wichtigste an jeder Erklärung ist die Auswahl der Dinge die man weglässt.Das Problem ist, dass Dinge gelernt, aber deren Sinn nicht verstanden wird, da einfach das Basiswissen fehlt.
Wenn jemanden ohne tiefgründige Vorbildung z.B. OOP beigebracht wird, kann er dies zwar anwenden, versteht aber nicht warum man z.B. Zugriffbereiche in Klassen definiert.
Schreibt er dann später selbstständig eine Anwendung, sieht er vielleicht auf einmal dass er z.B. in C++ garnicht diese endlose Definitionsschreiberei machen muss und einfach globale Funktionen und Variablen verwenden kann.
Oder er wendet OOP wenn es eigentlich unnütz/schädlich ist.
"XML" klingt verdammt cool und der Prof. hat auch duzende Gründe genannt warum man Informationen denn mit XML parsen sollte.
Im Berufsleben sieht man die frischen Ingenieure dann simpelste Konfigurationsdateien, usw. in XML parsen.
Denn sie haben es gelernt - ohne dessen Sinn zu verstehen.
Weil das die letzte Ebene ist wo man als Programmierer noch Zugriff darauf hat.
Das hängt auch ein wenig davon ab welche Programmiersprache man wählt, oder nicht?
Spasstiger
2006-11-23, 14:12:00
Hat hier eigentlich überhaupt jemand direkt mit OOP angefangen, als er das Programmieren lernte? Die Hürden sind wohl zu groß für einen Anfänger. Allerdings sollte man sich auch nicht zu lange nur mit prozeduraler Programmierung befassen, da man sich irgendwann zu sehr in das Prozedurale verbohrt und dann gar nichts mehr von OOP hören möchte. OOP erscheint ja für viele Probleme auf den ersten Blick umständlich und aufgeblasen. Aber wenn man ordentlich vorgeht mit Klassendiagrammen etc. kann man sich später viel leichter wieder in das Problem hineindenken, falls man mal Erweiterungen oder Änderungen vornehmen möchte.
Jemand, der mit Programmieren seine Brötchen verdienen möchte, sollte imo auf jeden Fall OOP beherrschen.
Monger
2006-11-23, 14:14:40
Wenn jemanden ohne tiefgründige Vorbildung z.B. OOP beigebracht wird, kann er dies zwar anwenden, versteht aber nicht warum man z.B. Zugriffbereiche in Klassen definiert.
Im Grunde heißt das nix anderes als "aus Schaden wird man klug". Also: man muss erst lernen wie man es nicht macht, bevor man lernt wie man es richtig macht.
So blöd ist das nicht, aber um das zu erklären, braucht man die Grundlagen nicht. In OOP ist Information Hiding ein Grundprinzip - was übrigens auch für jeden anderen Bereich nützlich ist. Selbst wenn ich Dokumentation schreibe, hilft mir dieser Grundsatz...
Also: dass man jemandem erst schlechte Gewohnheiten anerziehen muss, damit man sie ihm später wieder abgewöhnen kann, finde ich nicht gerade stichhaltig.
Im Grunde heißt das nix anderes als "aus Schaden wird man klug". Also: man muss erst lernen wie man es nicht macht, bevor man lernt wie man es richtig macht.
So blöd ist das nicht, aber um das zu erklären, braucht man die Grundlagen nicht. In OOP ist Information Hiding ein Grundprinzip - was übrigens auch für jeden anderen Bereich nützlich ist. Selbst wenn ich Dokumentation schreibe, hilft mir dieser Grundsatz...
Also: dass man jemandem erst schlechte Gewohnheiten anerziehen muss, damit man sie ihm später wieder abgewöhnen kann, finde ich nicht gerade stichhaltig.Das ist psychologisch ganz einfach zu verstehen finde ich.
Wenn die Gründe für ein Verfahren in einer Liste am Projektor aufgelistet werden, und der Student diese zur Prüfung lernen muss, versteht er sie nicht.
Er versteht sie erst wirklich wenn er selbst die Fehler gemacht hat.
Hat hier eigentlich überhaupt jemand direkt mit OOP angefangen, als er das Programmieren lernte?
"direkt mit OOP anfangen", was soll das sein? OOP ist vor allem anderen eine Strategie Programme zu strukturieren, wie soll man mit sowas anfangen können, wenn man Programme weder lesen noch schreiben oder verstehen kann?
Natürlich kann man Programme lesen/schreiben/verstehen auch in Sprachen mit OOP-Unterstützung lehren, wenn man das gut macht ist es genauso leicht oder schwer wie in Sprachen ohne OOP, nur man bekommt zusätzlich schon etwas von den Gründen mit, wieso OOP verwendet wird.
ethrandil
2006-11-23, 15:35:16
"direkt mit OOP anfangen", was soll das sein? OOP ist vor allem anderen eine Strategie Programme zu strukturieren, wie soll man mit sowas anfangen können, wenn man Programme weder lesen noch schreiben oder verstehen kann?
Naja, man kann Klassen, Methoden, Kapselung, Kohäsion auch abstrakt beibringen, ohne auf eine Sprache einzugehen.
- eth
Naja, man kann Klassen, Methoden, Kapselung, Kohäsion auch abstrakt beibringen, ohne auf eine Sprache einzugehen.
Mir geht es nicht um die Programmiersprache, sondern darum, dass man wissen muss was ein Programm ist und zwar nicht nur als Definition sondern auch wie man praktisch damit umgeht.
Die Konzepte von OOP sind ohne Zusammenhang mit Programmen ziemlich inhaltsleer. Etwas nützliches außer den Begriffen selbst kommt dabei nicht raus.
Ich bin völlig deiner Meinung. Einem Flugzeugpiloten sollte man nicht erklären wie Düsentriebwerke gebaut werden, sondern umso mehr wie er damit umgehen soll.
Du wirst lachen, aber die lernen wirklich wie die Dinger funktionieren um sie selbstständig vor dem Flug inspizieren zu können.
"Kleinkrams" zu können macht einen zum besseren Programmierer, auch wenn du dir das natürlich nicht eingestehen wirst. Es ist ja nicht so dass man sich danach damit rumschlagen muss.
Spasstiger
2006-11-23, 19:06:51
Ein Softwareingenieur von der Uni sollte auf jeden Fall wissen, wie objektorientierte Konzepte aussehen und in der Lage sein, diese auch auf konkrete Probleme anwenden zu können. Das Schreiben des Codes ist ja nur eine Arbeit, die auch an einen Fachinformatiker weiter delegiert werden kann, weshalb der Softwareingenieur nicht unbedingt die Feinheiten der Programmiersprachen kennen muss. Vielmehr muss er die generellen Konzepte hinter OOP verstehen (und was in Zukunft noch so kommt, z.B. agentenorientierte Systeme).
Der Softwareingenieur muss also nicht fliegen, sondern das Flugzeug bauen. ;)
Das Schreiben des Codes ist ja nur eine Arbeit, die auch an einen Fachinformatiker weiter delegiert werden kann, weshalb der Softwareingenieur nicht unbedingt die Feinheiten der Programmiersprachen kennen muss.
Ja, das ist eine populäre Ansicht. Ist meiner Meinung nach zu kurz gedacht, was geringer qualifizierte selbstständig erledigen können, kann oft auch automatisiert werden. Dafür muss man aber die Entwicklungsumgebung passend wählen und sehr genau kennen.
Monger
2006-11-23, 20:09:54
Du wirst lachen, aber die lernen wirklich wie die Dinger funktionieren um sie selbstständig vor dem Flug inspizieren zu können.
"Kleinkrams" zu können macht einen zum besseren Programmierer, auch wenn du dir das natürlich nicht eingestehen wirst. Es ist ja nicht so dass man sich danach damit rumschlagen muss.
Jaja, "Wir erwarten von unseren Mitarbeitern Flexibilität". In der Praxis muss man tatsächlich alles können. Das ist halt die einzige Lösung, wenn die Projektplanung versagt. Erlebe ich leider gerade im Moment mehr als deutlich...
Das heißt aber nicht, dass man mit Spezialisierung nicht viel weiter kommen würde. Die eierlegende Wollmilchsau ist der mieseste aller Kompromisse, und nicht der beste.
Headman
2006-11-23, 21:46:18
Ich hatte zu Beginn meiner C++ Zeit ein Buch mit dem Titel "C++ in 21 Tagen" von Jesse Liberty. Imo eines der besten C++/OOP Einsteigerbücher überhaupt.
Hier gibts das Buch, scheint sogar vollständig zu sein:
http://web.dadanini.com:7980/books/C++%20in%2021%20Tagen/inhalt.html
Das ist aber ziemlich mieserabel.
Edit: WUAA was da für Müll drinsteht. Unglaublich.
MadMan2k
2006-11-23, 22:18:40
also wir haben mit (dr)scheme angefangen, wobei Variablenzuweisung erst als letztes freigeschaltet wurde.
Damit musste man mit Rekursion und Scopes auskommen, anstatt mit Schleifen und Zustandsvariablen rumzupfuschen.
Damit ist man eigentlich ganz gut vorbereitet um die Komplexität eines Java sinnvoll nutzen zu können.
MadMan2k
2006-11-23, 22:35:26
.
Hm okay, ich dacht schon. Bei uns gibts nämlich auch son Scheme-Prof X-D
Hier gibts das Buch, scheint sogar vollständig zu sein:
http://web.dadanini.com:7980/books/C++%20in%2021%20Tagen/inhalt.html
lol mit dem buch wollt ich auch mal anfangen
springt dann von halloworld.cpp zu
"your code to place" übungen
mmn ganz schlecht für anfänger man ist sozusagen von unverständlichem code umzingelt
lol mit dem buch wollt ich auch mal anfangen
springt dann von halloworld.cpp zu
"your code to place" übungen
mmn ganz schlecht für anfänger man ist sozusagen von unverständlichem code umzingelt
Es wurde auch gar nicht nach einem Buch für Anfänge gefragt, sondern nach einem Buch für OO Umsteiger die vorher Prozedural programmiert haben.
PH4Real
2006-11-23, 22:59:25
also wir haben mit (dr)scheme angefangen, wobei Variablenzuweisung erst als letztes freigeschaltet wurde.
Damit musste man mit Rekursion und Scopes auskommen, anstatt mit Schleifen und Zustandsvariablen rumzupfuschen.
Damit ist man eigentlich ganz gut vorbereitet um die Komplexität eines Java sinnvoll nutzen zu können.
Ich auch :biggrin: ... ach das waren noch (Klammer-) Zeiten...
Zum Topic: Würde gleich anfangen den Leuten OOP anhand von abstrakten Beispielen oder auch "Übungsobjekte" beizubringen und dann Stück für Stück erst "tiefer" gehen. Es gab mal so ein Übungsbuch dem lag eine Übungsbibliothek bei... das fand ich gar nicht mal so schlecht (Name leider vergessen).
Die ersten Aufgaben waren dann auch nicht "Schreiben sie eine for-Schleife, die..", sondern es gibt ein Objekt "Auto", das macht das und das. Wie sie das macht, hat sie nicht zu interessieren aber erweitern sie doch mal die Funktionalität um dieses oder jenes mittels Vererbung etc. Erst in Kapitel 10 des Buches kamen Schritt für Schritt die Erklärung der ganzen Statements, Variablen und Expressions. Fand die Idee gut, weil so die Konzepte im Vordergrund standen.
ScottManDeath
2006-11-23, 23:17:13
Ein Softwareingenieur von der Uni sollte auf jeden Fall wissen, wie objektorientierte Konzepte aussehen und in der Lage sein, diese auch auf konkrete Probleme anwenden zu können. Das Schreiben des Codes ist ja nur eine Arbeit, die auch an einen Fachinformatiker weiter delegiert werden kann, weshalb der Softwareingenieur nicht unbedingt die Feinheiten der Programmiersprachen kennen muss. Vielmehr muss er die generellen Konzepte hinter OOP verstehen (und was in Zukunft noch so kommt, z.B. agentenorientierte Systeme).
In Anlehnung an ein bekanntes(?) Sprichwort: Kein Design überlebt den ersten Build ;)
Wenn ich keinen Plan habe, wie Low Level coden geht, wie soll ich dann flexible und robuste Designs machen können? Etwa im BWLer Style (no offense intended) ein paar Buzzwords hinklatschen und ein paar UML Diagramme hinkritzeln und dann den Programmierschweinen sagen, codet das mal? ;)
Dat wird nix. Nur gute und erfahrende Programmierer können potentiell zu guten Designern / Architekten werden. Alles andere halte ich für ziemlich gewagt... Und die Uni macht einem weder zu einem, noch einem anderen ;D
PH4Real
2006-11-23, 23:27:50
In Anlehnung an ein bekanntes(?) Sprichwort: Kein Design überlebt den ersten Build ;)
Wenn ich keinen Plan habe, wie Low Level coden geht, wie soll ich dann flexible und robuste Designs machen können? Etwa im BWLer Style (no offense intended) ein paar Buzzwords hinklatschen und ein paar UML Diagramme hinkritzeln und dann den Programmierschweinen sagen, codet das mal? ;)
Dat wird nix. Nur gute und erfahrende Programmierer können potentiell zu guten Designern / Architekten werden. Alles andere halte ich für ziemlich gewagt... Und die Uni macht einem weder zu einem, noch einem anderen ;D
Das ist so ungefähr das Problem mit den Architekten auch im Bauwesen und den Handwerkern... Keiner würde behaupten, dass jeder Architekt vorher eine Ausbildung als Maurer machen sollte, aber ich kenne Architekten, die es genau so gemacht haben.
Und manchmal hat man mit Architekten zu tun, da weiß man schon als Laie, dass das nie so funktionieren kann bzw. das Budget reißen wird, weil man merkt, dass derjenigen einfache Grundlagen (der Programmierung oder des Bauwesens) nicht beachtet hat ;). Ein guter Architekt kennt eventuelle Fallstricke.
Demirug
2006-11-23, 23:51:55
Wenn ich keinen Plan habe, wie Low Level coden geht, wie soll ich dann flexible und robuste Designs machen können? Etwa im BWLer Style (no offense intended) ein paar Buzzwords hinklatschen und ein paar UML Diagramme hinkritzeln und dann den Programmierschweinen sagen, codet das mal? ;)
Ich kenne einen Fall wo das versucht wurde. Nachdem man zwei Jahre das Design Dokument geschrieben hat wurde das Projekt 3 Monate nachdem die „Programmierer“ mit der Arbeit begonnen hatten eingestellt. Das Design war unter Einhaltung der geforderten Performances einfach nicht realisierbar.
Inzwischen scheint der Trend ja klar zu den agilen Methoden zu gehen.
"direkt mit OOP anfangen", was soll das sein? bei einem einfachen Hallo-Welt-Programm die Ausgaberoutine in einer Methode einer Klasse realisieren, z.B.
OOP ist vor allem anderen eine Strategie Programme zu strukturieren, wie soll man mit sowas anfangen können, wenn man Programme weder lesen noch schreiben oder verstehen kann?eine Struktur zu bauen, die nur eine einzige Unterstruktur hat (hier: eine Klasse mit nur einer einzigen Methode), ist durchaus möglich. Auch wenn es den Sinn der Struktur nicht erkennen läßt.
Natürlich kann man Programme lesen/schreiben/verstehen auch in Sprachen mit OOP-Unterstützung lehren, wenn man das gut macht ist es genauso leicht oder schwer wie in Sprachen ohne OOP, nur man bekommt zusätzlich schon etwas von den Gründen mit, wieso OOP verwendet wird.eben nicht. Weil OOP einem dann so selbstverständlich erscheint, daß man gar nicht auf die Idee kommt, daß es auch anders ginge. Und dann kommt man auch nicht auf die Idee zu fragen, wozu OOP eigentlich da ist.
Das hängt auch ein wenig davon ab welche Programmiersprache man wählt, oder nicht?aber egal welche du wählst, keine wird dir Zugriff zu tieferen Ebenen als den CPU-Registern geben ;)
Spasstiger
2006-11-24, 01:30:05
bei einem einfachen Hallo-Welt-Programm die Ausgaberoutine in einer Methode einer Klasse realisieren, z.B.
Oder z.B. ein Programm, das einen bzw. mehrere Würfel realisiert. Man kann dann von einer Klasse "Brettspiel" aus, welche die main-Methode enthält, Würfel-Objekte der Klasse "Wuerfel" erzeugen. Dabei stehen als Methoden dann z.B. wuerfeln() und getValue() zur Verfügung.
Das wäre ein anschauliches Beispiel für OOP, welches keine Kenntnisse über prozedurales Programmieren voraussetzt.
Und man kann das Programm auch leicht um weitere Funktionalitäten erweitern. Typischen prozedurale Elemente wie Schleifen, if-Abfragen, etc. könnten dann auch Stück für Stück eingeführt werden (z.B. durch eine Methode, die in Abhängigkeit von der gewürfelten Zahl eine Aktion auf dem Spielfeld auslöst).
wo das ein völlig anderer Ansatz ist, mußt du mir aber erstmal erklären. Soweit ich seit meinem Einstieg in die OOP sehe - und worin ich seither auch durch nichts widerlegt wurde - hat OOP in erster Linie die Aufgabe, eine Ordnungsstruktur oberhalb der Ebene der Funktionen und Prozeduren zu etablieren, sprich: Prozeduren thematisch zu ordnen, indem man diejenigen unter ihnen, die für eine bestimmte Kollektion von Daten relevant sind, zu Methoden einer einzigen Klasse macht und dabei zugleich ebenjene Kollektion von Daten, die sonst ein wild wucherndes Dasein als lokale Variablen, Parameter und Rückgabewerte fristen würden, in Form von Datenmembern in dieses Ordnungskonstrukt mit einbezieht.
Ist doch ganz einfach.
Bei einer rein prozeduralen Programmierung mußt du die Klasse nie verlassen
und damit brauchst du auch nicht wissen, wie Objekte von Klassen miteinander zu interagieren haben.
Letzteres ist nämlich das eigentliche Problem als Programmierer, der prozedural programmiert hat und die OOP lernen will.
Allein Java wirft einem als Anfänger genug Klötze ans Bein, sobald man zu einem anderen Objekt wechseln will.
Matrix316
2007-06-28, 11:54:06
Ich finde das komplizierteste an OOP ist, wie es oft erklärt wird. Wenn dann Leute von Fahrzeugen, Autos, Reifen und irgendwelchen Abstrakten Gegenständen anfangen, hörts schon auf.
Wer z.B. mit einer prozeduralen Programmierung anfängt und dann ins Objektorientierte gehen will, muss sich einfach nur vorstellen: "Eine Klasse ist auch nur ein spezieller Struct." :D Und schon ist "OOP" garkein so großes Mysterium mehr.
Monger
2007-06-28, 13:02:05
Wer z.B. mit einer prozeduralen Programmierung anfängt und dann ins Objektorientierte gehen will, muss sich einfach nur vorstellen: "Eine Klasse ist auch nur ein spezieller Struct." :D Und schon ist "OOP" garkein so großes Mysterium mehr.
Und genau diese Denkweise produziert imho den miesesten Code.
Bei Leute die lange Zeit prozedural programmiert haben, sehe ich oftmals diese riesigen Switch-Case Gebilde und If-Bäume. Wenn man erstmal begreift, dass sich in OOP alles um Ähnlichkeit und Abstraktion dreht, kann man Probleme völlig anders angehen.
Ich stehe hier gerade vor genau diesem Problem, weil die Abteilung hier erst vor kurzem auf das aktuelle Visual Studio umgestiegen ist, und bis zu dem Zeitpunkt schlicht noch nie was mit Objektorientierung gemacht hat. Natürlich kann man im Prinzip die alten C-Code Algorithmen 1:1 übertragen. Nur hat man dann 5mal so viel Code wie man müsste, und damit auch alle Probleme die damit einhergehen wie Wartbarkeit und Wiederverwendbarkeit.
Und genau diese Denkweise produziert imho den miesesten Code.wenn man auf dieser Erkenntnisstufe stehenbleibt, mag das stimmen. Das darf natürlich nur den Einstieg in die OOP-Welt bilden, danach muß man immer noch weiter denken.
Bei Leute die lange Zeit prozedural programmiert haben, sehe ich oftmals diese riesigen Switch-Case Gebilde und If-Bäume. Wenn man erstmal begreift, dass sich in OOP alles um Ähnlichkeit und Abstraktion dreht, kann man Probleme völlig anders angehen.also würde ich jetzt aber gerne mal näher erklärt haben. Kannst du mal ein Beispiel bringen? Inwiefern soll OOP eine Alternative zu Verzweigungen bieten? Redest du von Vererbung und virtuellen Funktionen?
Matrix316
2007-06-28, 14:12:47
Das würde ich auch gerne wissen, wie man switch case oder if mit Klassen und Methoden umgehen will.
eXistence
2007-06-28, 14:36:06
also würde ich jetzt aber gerne mal näher erklärt haben. Kannst du mal ein Beispiel bringen? Inwiefern soll OOP eine Alternative zu Verzweigungen bieten? Redest du von Vererbung und virtuellen Funktionen?
Ich vermute Monger spielt auf Polymorphismus an.
Man muss oft nicht mehr zwischen unterschiedlichen Typen unterscheiden, weil das Objekt im Idealfall selbst weiß, wie es sich zu verhalten hat.
switch und if werde natürlich nicht überflüssig, nur im Umgang mit unterschiedlichen Ausprägungen eines Typs
govou
2007-06-28, 15:22:29
Bei uns ging's gleich im ersten Semester mit OOP in Java los. Vererbung, Patterns, Polymorphie, Interfaces usw. Die Leute ohne Vorkenntnisse hatten es wirklich schwer sich dort durchzumogeln. Ich habe schließlich auch mit QBasic angefangen und es hat mir nicht geschadet. Was bringt einem OOP, wenn man nichtmal wirklich weiß, was ein IF-Statement ist oder wie Schleifen aufgebaut werden :rolleyes:.
Endorphine
2007-06-28, 15:33:45
Darf ich mal zum ursprünglichen Thread zurückkommen? :D
Ich hab das Buch jetzt nicht komplett durchgelesen/gearbeitet, aber die Kapitel, die ich gelesen habe, haben mir ganz gut gefallen: http://www.galileocomputing.de/openbook/oo/
Damit kann man meiner Meinung nach als Einsteiger das Konzept der OOP verstehen lernen.
Monger
2007-06-28, 15:49:20
also würde ich jetzt aber gerne mal näher erklärt haben. Kannst du mal ein Beispiel bringen? Inwiefern soll OOP eine Alternative zu Verzweigungen bieten? Redest du von Vererbung und virtuellen Funktionen?
Solange ich mit Java und C# zu tun habe, habe ich noch nicht ein einziges mal eine Switch/Case Anweisung gebraucht. Immer dann wenn es mehr als ein, zwei Varianten gibt, lohnt sich imho Vererbung. Auf If kann man natürlich nicht völlig verzichten, aber geschachtelte If Anweisungen (möglichst noch auf drei oder mehr Ebenen) sind immer ein Anzeichen dafür, dass irgendwas windschief ist.
Mal ein etwas arg konstruiertes Beispiel: Ein Taschenrechner soll einen bestimmten Wert mit einer bestimmten Operation bearbeiten. Klassischer Ansatz:
public enum Kalkulation{
Addieren,
Subtrahieren,
Multiplizieren,
Dividieren;
}
public void foo2(Kalkulation operation, int value1, int value2){
int ergebnis = 0;
switch(operation){
case Addieren: ergebnis = value1 + value2; break;
case Subtrahieren: ergebnis = value1 - value2; break;
case Multiplizieren: ergebnis = value1 * value2; break;
case Dividieren: ergebnis = value1 / value2; break;
default: ergebnis = 0;
}
}
Das wäre also die Variante mit Switch/Case. Man kann das auch anders formulieren:
public enum Kalkulation{
Addieren{
public int calc(int val1, int val2){
return val1 + val2;
}},
Subtrahieren{
public int calc(int val1, int val2){
return val1 - val2;
}},
Multiplizieren{
public int calc(int val1, int val2){
return val1 * val2;
}},
Dividieren{
public int calc(int val1, int val2){
return val1 / val2;
}};
public abstract int calc(int val1, int val2);
}
public void foo(Kalkulation operation, int value1, int value2){
int ergebnis = operation.calc(value1, value2);
}
Macht absolut genau das selbe, nur ohne Switch/Case. Das Beispiel ist ein bißchen arg mit Kanonen auf Spatzen geschossen, aber die Idee sollte klar sein.
Matrix316
2007-06-28, 16:53:29
Und in welcher Programmiersprache kann man Funktionen als Enum Members verwenden? :rolleyes:
Monger
2007-06-28, 17:23:23
Und in welcher Programmiersprache kann man Funktionen als Enum Members verwenden? :rolleyes:
Java.
Darf ich mal zum ursprünglichen Thread zurückkommen? :D
Ich hab das Buch jetzt nicht komplett durchgelesen/gearbeitet, aber die Kapitel, die ich gelesen habe, haben mir ganz gut gefallen: http://www.galileocomputing.de/openbook/oo/
Damit kann man meiner Meinung nach als Einsteiger das Konzept der OOP verstehen lernen.
THX
Java.
Das kann ja nun nicht der Sinn sein, Logik in enums zu kapseln. Sieht jedenfalls sehr fragwürdig aus.
Ectoplasma
2007-06-29, 16:02:25
Ein Softwareingenieur von der Uni sollte auf jeden Fall wissen, wie objektorientierte Konzepte aussehen und in der Lage sein, diese auch auf konkrete Probleme anwenden zu können. Das Schreiben des Codes ist ja nur eine Arbeit, die auch an einen Fachinformatiker weiter delegiert werden kann, weshalb der Softwareingenieur nicht unbedingt die Feinheiten der Programmiersprachen kennen muss. Vielmehr muss er die generellen Konzepte hinter OOP verstehen (und was in Zukunft noch so kommt, z.B. agentenorientierte Systeme).
Der Softwareingenieur muss also nicht fliegen, sondern das Flugzeug bauen. ;)
Diese Trennung zwischen Softwareingenieur und Fachinformatiker kommt in der Praxis so gut wie gar nicht vor. Und was soll der Unterschied UNI und FH eigentlich? Gerade im Informatik Bereich wird das Thema UNI oder FH absolut überbewertet. Gerade die Software und deren Konzepte leben von der Praxis. Es gibt in dem Bereich kaum eine Theorie die nur aus sich heraus entstanden ist.
Zum Thema:
Objektorientierung, bzw. eine Objekthierarchie mit Vererbung, Aggregation und der Kommunikation der Objekte untereinander, ist Symantik pur. Das Verständnis erlernt man aus der Praxis und konkreten Problemen der Umwelt. Deshalb sagt man auch "natürlich" dazu. Man darf aber das Wort "natürlich" nicht mit "einfach" gleichsetzen. Dann kommen noch ein paar Dinge wie Design - Patterns und diverse Begrifflichkeiten der OO Welt hinzu.
Ein Nachteil der Objektorientierung ist leider, dass gerade viele Begrifflichkeiten mehrdeutig sind. Und das ist nach meiner Meinung nach eines der großen Probleme, bei der Erlernung von objektorientierten Konzepten.
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.