Mal so oberflächlich wurde die selbe Frage hier ja schon unzählige Male gestellt, aber nicht von mir ^^ . Auf Arbeit kommen immer mehr Kollegen auf mich zu, die sich gerne in VB.NET bzw. C# einarbeiten würden. Allerdings: nach dem einwöchigen Kurs hier wissen sie zugleich alles und nichts. Bücher wie die "Von Kopf bis Fuß" Reihe sind zwar ein netter Einstieg um mal mit einem konkreten Anwendungsbeispiel durchzusteigen, und die Bücher von Galileo Computing sind als Referenzhandbücher ganz nützlich... Aber ich merke, dass da der theoretische Unterbau fehlt. Im Prinzip das, was man im Studium vermittelt kriegt. Die Leute kommen aus solchen Aktionen mit vollen Köpfen raus, setzen sich an ihre Entwicklungsumgebung dran, und scheitern spätestens an der fünften Codezeile, weil ihnen halt der Blick fürs große Ganze fehlt, und wie man Probleme abstrahiert. Dass man nicht mit zwei Büchern drei, vier Jahre Studium ersetzen kann ist mir klar. Aber irgendwo muss man ja mal anfangen. Deshalb: was ich suche, wäre ein Buch was mal tatsächlich auf die Theorie eingeht: was sind Klassen, was Objekte? Wann lädt die Runtime was? Was ist der Unterschied zwischen Methoden, Properties und Feldern, und wann benutzt man welche? Was sind Iteratoren, was ist lazy Evaluation? Was sind Value und Reference Types, und wann nimmt man welche? Was heißt Call-By-Value in .NET? Noch besser wären methodische Fragen, also z.B. wie nähere ich mich einer großen Implementierung Stück für Stück an? Sozusagen TDD für Dummies. Wie komme ich an Informationen ran die mir fehlen? Klar kann man sich das auch alles aus der MSDN zusammenstückeln, aber es ist für einen Anfänger kaum bewältigbar, weil ohne Erfahrung weiß man ja gar nicht wo man suchen soll, und nach was. Kennt zufällig jemand von euch geeignete Literatur? Im Zweifel auch gerne von anderen modernen Hochsprachen, also z.B. Java, Python etc. , damit ich mal vergleichen kann. Wenn es was taugt, darf es auch durchaus Geld kosten, hier geht es nunmal nicht um Freizeitaktivitäten.
mongo schrieb: > weil ihnen halt der Blick fürs große Ganze fehlt, > und wie man Probleme abstrahiert Das ist aber nichts was man an Büchern oder einer konkreten Programmiersprache lernt. Alle Theorie kann die Praxis nicht ersetzen (auch ein Studium nicht), man muss einfach mal "machen". Dann wird man auf Probleme stoßen, und diese Probleme kann man dann versuchen mit neuen Konzepten (z.B. OOP) zu lösen, am besten indem man das alte Wegwirft und nochmal neu macht. mongo schrieb: > was sind [...] Ich glaub jedes Buch erklärt was der Begriff bedeutet, was "das" wirklich ist erkennt man aber erst viel später. Also was genau ist dir Unklar? Viele deiner W-Fragen sind auch a) uninterresant für das Verständnis OOP b) an eine konkrete Sprache gebunden
mongo schrieb: > Deshalb: was ich suche, wäre ein Buch was mal tatsächlich auf die > Theorie eingeht: was sind Klassen, was Objekte? Wann lädt die Runtime > was? Was ist der Unterschied zwischen Methoden, Properties und Feldern, > und wann benutzt man welche? Was sind Iteratoren, was ist lazy > Evaluation? Was sind Value und Reference Types, und wann nimmt man > welche? Was heißt Call-By-Value in .NET? Das steht in jedem Buch drin. Das Problem ist, daß es einem erst richtig klar wird, wenn man etwas damit macht. Abgesehen davon ist das Wichtigste, daß man die Klassenbibliothek mit der man arbeitet, mindestens so gut kennt, wie seine Frau. Ergo: Softwareentwicklung ist reine Erfahrungssache.
Meiner Meinung nach, kann man OOP nicht für sich alleine lernen wenn man keine OO Erfahrungen hat. Ich denke da gehört auch Software Engineering und OOA dazu, erst dann kommt der Sinn von OOP richtig zur Geltung und der Kreis schliesst sich. Demnach würde ich folgendes Buch empfehlen: http://www.amazon.de/Objektorientierte-Softwareentwicklung-Analyse-Modeling-Language/dp/3486255738 Oder eine sauber Weiterbildung (kein Kurs). Grüsse, René
Entwickler die danach Fragen wie sie etwas lernen und Entwickler die Galileo Computer Bücher benutzen. Möchtest du den Namen deiner Firma nennen? Dann weiß ich wo ich mich auf jedenfall nicht bewerbe.
Das Ganze OOP ist relativ trivial. Vorher hatte man globale Variablen und globalre Proceduren die darauf was machten. Mit OOP fasst man zusammengehoerige Strukturen zusammen. Also Proceduren und Daten zusammen ergeben ein Objekt. Die Bauvorschrift fuer ein Objekt nennt sich Klasse. Resp eine Instanz einer Klasse nennt man Objekt. Die Proceduren, die zu einer Klasse gehoeren, nennt man Memberfunktionen. Nach aussen sichtbaren Daten eines Objektes nennt man Eigenschaften (Properties). Ein paar Begriffe. Encapsulation. man definiert objektinterne Procedure als privat, die sind von ausserhalb nicht sichtbar und auch nicht ausfuehrbar. Vererbung. Beginnend mit einer einfachen Klasse kann man weitere Klassen bilden, indem man der Vorgaengerklasse zusaetzliche Eigenschaften (Daten) sowie zusaetzliche Funktionalitaet (Procedure, Memberfunktionen) verpasst. Es gibt dann auch noch befreundete Klassen usw.
Um aus der OOP Nutzen ziehen zu können, muss man sich erst einmal klar machen, worin dieser Nutzen überhaupt besteht. Sonst läuft es darauf hinaus, dass man (wie viele) OOP um der OOP Willen macht, und man steckt jede Menge Energie hinein, ohne dass ein wirklicher Gewinn dabei herausspringt. Die meisten Programmierparadigmen sind mit dem Ziel entwickelt worden, die Produktivität bei der Softwareentwicklung zu erhöhen durch - gute Beherrschbarkeit auch großer Softwareprojekte, - leichte Wiederverwendbarkeit von Softwareteilen und - Beseitigung häufiger Fehlerquellen. OOP hat sich vor allem die ersten beiden Punkte (Beherrschbarkeit und Wiederverwendbarkeit) auf die Fahnen geschrieben und kann dabei tatsächlich eine große Hilfe darstellen. Leider vermitteln die meisten OOP-Bücher dem Anfängere den Eindruck, die Beherrschbarkeit und die Wiederverwendbarkeit würden durch OOP automatisch verbessert. Ausgehend von dieser falschen Prämisse stellen diese Bücher im Wesentlichen eine Anleitung dafür dar, wie die zu entwickelnde Software in irgendeiner Weise mit einer OO-Struktur versehen werden kann. Inwieweit diese Struktur tatsächlich dem Wunsch nach besserer Beherrschbarkeit und Wiederverwendbarkeit entgegenkommt, scheint dabei oft zweitrangig zu sein. Es gibt ein paar Probleme, auf die man früher oder später stößt und die ein wenig an der reinen OO-Lehre zerren, weswegen sie in der Literatur gerne unter den Teppich gekehrt werden. Beispiele: - Leichte Beherrschbarkeit und Wiederverwendbarkeit widersprechen sich oft. Man muss sich dann bei der Festlegung der Softwarestruktur entscheiden, welchem der beiden Aspekte man den Vorzug gibt. - Gewisse Aufgabenstellungen lassen sich von ihrer Natur her nicht sinnvoll in ein OO-Korsett zwängen. Es ist dann nicht falsch, sondern sogar klug, die entsprechenden Programmteile mit prozeduralen Elementen zu implementieren. Diese Probleme wären gar keine, wenn sie in der Literatur zusammen mit Entscheidungshilfen zu deren Lösung offen auf den Tisch gelegt würden. Ich möchte die OOP-Literatur aber nicht schlecht reden, man sollte sie nur nicht überbewerten. Zudem kenne ich kein Buch zu dem Thema, das ich guten Gewissens als so eine Art Bibel empfehlen könnte. Man kann sich aber durchaus so ein Buch schnappen (am besten kein allzu dickes, damit man mit dem Lesen auch irgendwann wieder fertig wird ;-)) und sich darin die Grundbegriffe und ein paar Grundtechniken erarbeiten. Dann kommt aber kein zweites Buch, sondern der Schritt in die Realität. Dieser sieht so aus, dass man sich Code von anderen anschaut und die konzeptionellen Rosinen herauspickt. Das läuft bei mir oft folgendermaßen ab: Ich möchte an irgendeiner riesigen Open-Source-Anwendung kleine Änderungen vornehmen, finde mich in dieser Software wider Erwarten sofort zurecht, und habe die Änderungen in erstaunlich kurzer Zeit erledigt. Oder ich stelle fest, dass es da eine Open-Source-Bibliothek gibt, die ich immer wieder gerne in ganz unterschiedlichen Projekten verwende, weil deren Datentypen und Funktionen/Methoden an vielen Stellen nahtlos in meinen eigenen Code passen. In beiden Fällen sage ich mir: Genauso wie die Entwickler dieser Anwendung bzw. der Bibliothek will ich es auch können und versuche durch Analyse der Softwarestruktur, der APIs, der Datentypen und ggf. auch der einzelnen Funktionen und Methoden das Geheimnis zur ergründen, warum ich mit der Software so gut zurecht komme. Die zugrundeliegenden Ideen verwende ich dann zukünftig auch in meinen eignenen Softwareprojekten.
Siebzehn mal Fuenfzehn schrieb: > Mit OOP fasst man zusammengehoerige Strukturen zusammen. Also Proceduren > und Daten zusammen ergeben ein Objekt. In CLOS ist das anders.
Die Schwierigkeiten beim weiterfuehrenden Einsatz von OOP sind die Libraries. Die vorgeferigten Klassen kommen mit einem ueberladen erscheinenden Funktionssatz daher. zB Image1.Canvas.Pen.Color:=clBlack; Das ist ein List von angeflanschten Eigenschaften, die alle etwas bedeuten. Da muss man sich eben einarbeiten. In die Library. Wenn dieselbe Funktionalitaet als Vor-OOP daherkaeme, waere sie um Groessenordnungen unuebersichlicher. Als Beispiel mag die MFC : Microsoft Foundation Class dienen, aus der WinNT Zeit. Deren Standardinterface war LParam : pointer; LCount:integer; Da kann man alles anflanschen. Theoretisch. Das Falsche hat einfach nicht funktioniert. Delphi hat dann MFC auf OOP umgebogen. Und das wurde dann spaeter duch Dot-Net abgekupfert, resp verschlechtert.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.