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.
