Hallo, ich habe ein Problem das ich Euch gerne schildern würde. Ich möchte C# erlernen wobei ich nicht das Problem beim schrieben des C# Codes habe! Soll heißen das ich die Grundlagen der Sprache beherrsche aber diese Grundlagen nicht einsetzen kann. Zum Beispiel weiß ich wie man eine Klasse erstellt aber nicht wann es sinnvoll ist. Könnt Ihr das verstehen ? In den Büchern die ich gekauft und gelesen habe sind meiner Meinung keine Praxis gerechten Beispiele vorhanden! Wie und wann sollte man DLL's erstellen wann? Ich hoffe das ich mich einigermasen deutlich ausgedrückt habe und dass Ihr mir Gute Pc programier literatur oder Tutorials empfehlen könnt. Vielen Dank für Eure Hilfe Gruß Sven
Hi Sven, O'Reilly: Entwurfsmuster von Kopf bis Fuß: http://www.oreilly.de/catalog/hfdesignpatger/ O'Reilly: Objektorientierte Analyse und Design von Kopf bis Fuß: http://www.oreilly.de/catalog/hfobjectsger/ Teuer, unkonventionell und sehr gut! Bin auch gerade dabei mich in gute Softwarearchitektur/-design einzulesen und beide Bücher sind dabei sehr hilfreich. Sehr ausführliche Herangehensweise an die Beispiele. Die Bücher bestehen aus vielen Beispielen und Merkregeln, das alles aufeinander aufbaut/ineinander greift. Der Aufbau ist eigentlich folgender: Es wird ein Problem beschrieben, dann eine Lösung präsentiert. Hatte oft den Effekt, dass ich eigentlich auf genau die gleiche Lösung gekommen bin (freu), dann aber im nächsten Abschnitt die Erklärung stand, dass und WEIL das zuvor geschriebene noch verbessert werden kann. :-) Dann sofort gedacht, ja klar, das Neue/Erweiterte ist ganz klar viel besser. So hätte ichs jetzt auch gemacht. Dann nächstes Kapitel, und jetzt kann man noch dies und das verbessern... Wirklich gute Methodik. Also nicht nur Hingeklatsche von Beispielen, sondern ERARBEITEN von Lösungen. Ich hatte mit dem oberen Buch angefangen und würde das wieder so tun.
Tipp: Programmieren um des Programmierens Willen bringt nix, ebensowenig künstliche und herbeigezogene Beispiele. Programmier dein Projekt -- du wirst von ganz alleine an Punkte kommen, wo du dir denkst, 'Mensch, das wird immer konfuser|komplexer|chaotischer|länger', und wenn du da stehst, erarbeite dir ne Lösung an deinem Problem, nich an irgendwelchen Entchen und Gequake, sondern an deinem konkreten Problem. Es ist überdies m.M.n. auch völlig normal, dass man zu Beginn ein Projekt mal umwirft und neu aufstellt. Du wirst immer wieder Aspekte entdecken, die ein neues Konzept erfordern, auch wenn du dir vorher monatelang den Kopf zerplant hast.
C#möchtegern schrieb:
> Wie und wann sollte man DLL's erstellen
Na zum Beispiel wenn Du Funktionalität hast, die Du auch in anderen
Programmen wiederverwenden willst. Wenn man noch an seinem ersten
kleineren Projektchen werkelt, muss man freilich erst mal so weit kommen
;-)
Sieht vielversprechend aus! Ich hoffe das Buch ist das Geld wert. Kennt sonst noch jemand etwas in der Art. Danke für den Tip Gruß Seven
> wenn du da stehst, erarbeite dir ne Lösung an deinem Problem, nich an > irgendwelchen Entchen und Gequake, sondern an deinem konkreten Problem. Wenn du eine Schraube reindrehen willst, aber nicht weisst, dass es einen Schraubendreher gibt, dann kommst du alleine nicht weiter. Wenn der "Schraubendreher" dann halt in Form von quakenden Enten kommt (die Transferleistung kriegt man dann hin) - warum nicht? > Du wirst immer wieder Aspekte entdecken, die ein neues Konzept erfordern, > auch wenn du dir vorher monatelang den Kopf zerplant hast. Ja, deshalb ist z.B. eine Aussage des zweiten Buchs: Mach erst dasses läuft, machs dann erst flexibel, schön und wartbar. Danach dann in die nächste Runde... alles ein iterativer Prozess. Nicht zu viel auf einmal. Ach übrigens, fürs Verständnis von .net (Gui-Zeugs usw.) hat mir auch Charles Petzold sehr weitergeholfen: http://www.amazon.de/Windows-Programmierung-mit-Visual-C/dp/3860636529 und das Update auf .net 2.0: http://www.amazon.de/Windows-Forms-Programmierung-Visual-sharp-2005/dp/3860639854
Rainer schrieb: >> wenn du da stehst, erarbeite dir ne Lösung an deinem Problem, nich an >> irgendwelchen Entchen und Gequake, sondern an deinem konkreten Problem. > Wenn du eine Schraube reindrehen willst, aber nicht weisst, dass es > einen Schraubendreher gibt, dann kommst du alleine nicht weiter. Wenn > der "Schraubendreher" dann halt in Form von quakenden Enten kommt (die > Transferleistung kriegt man dann hin) - warum nicht? Nich alles, was hinkt, .. :-) Ich meins eher so: Du gehst ja auch nicht zuerst hin und übst den Umgang mit dem Akkuschrauber und -bohrer, informierst dich über allerhand erhältliche Schrauben- und Dübeltypen und so weiter, für den Fall, dass du irgendwann mal ein Bild aufhängen möchtest. Wenn du ein Bild hast, guckste nach der Wand, findest nen passenden Dübel, bohrst und gut is. Lern es, wenn du es brauchst, und dann ordentlich und konkret. Bringt mehr, als nachher immer wieder an abstruse bis abstrakte Beispiele zu denken und zu grübel, welches denn nun am besten passt. Es gibt nunmal nicht den goldenen Weg, an den man sich hält -- kreative Probleme erfordern kreative Lösungen.
> Nich alles, was hinkt, .. :-) Ich gebs zu, aber die Idee dahinter ist ja rübergekommen. > Ich meins eher so: Du gehst ja auch nicht zuerst hin und übst den Umgang > mit dem Akkuschrauber[...] Da sind wir uns absolut einig. > kreative Probleme erfordern kreative Lösungen. Ich hätte gerne eine "handwerkliche" Lösung, die mich definiert (und nicht zufällig) ans Ziel bringt. Für jeden Mist gibts anerkannte "Schritt-für-Schritt-Verfahren", nur für den "kreativen" Teil der SW-Entwicklung soll das nicht gelten. Das will ich nicht glauben. :-) Der E-Ing. plant seinen Schaltplan aus AppNotes und Datenblätter, zeichnet alles "standardisiert" auf, macht das Layout und erhalt ein Produkt das er mit Methoden entwickelt hat, die zu messbaren Qualitätsergebnissen führen. Jeden einzelnen Punkt kann er nachlesen. 90% aller Projekte kommen so zum Ziel. Nur in der Softwareentwicklung soll alles hauptsächlich Bauchsache sein? Genau diese Bauchsache muss doch irgendwann in Erfahrung münden. Diese muss sich formulieren (und in ein Buch bringen) lassen. Aber scheinbar gibts nicht so viele (oder zuviele?) allgemeingültige Verfahren oder keiner will das aufschreiben?!? (Mit Softwareentwicklung meine ich hier Design/Konzept erstellen und den Schritt zur Implementierung; den Rest vom ganzen Entwicklungsprozess hat man ja inzwischen schon besser im Griff).
Das gibts in der SW auch: Statt Bauteilen und Datenblättern hast du Bibliotheken, APIs und deren Dokumentation mit Beispielen. Statt etablierten Geräten spickst du halt in anderen Programmen. Für viele Dinge gibts ja handwerkliche Methoden, quasi 'Idiome': Der Aufruf von select() auf Unix folgt beispielsweise i.d.R. einem gängigen Schema, das sich auch im Quelltext wiederfindet. Genauso der Aufbau von QT-Programmen oder von Programmen überhaupt (main(), getopt(), ...). In der Elektrik haste dafür halt etablierte Schaltungen (Royer-Wandler, Sinusoszillator...) und Methoden (Knotenspannungsanalyse, ...). Aber du wirst jetzt keine Checkliste finden, mit der du ein Projekt erledigst, so von wegen 'ich brauche einen Fluxkompensator' -- Schritt 1, Schritt 2, Schritt 3, fertig ist der Fluxkompensator. QS gibts in der SW genauso wie in der HW. Und seien es simple Dinge wie 'keine 90°-Knicke in Leiterbahnen' und 'vermeide gets()'. Aber damit strickt sich noch lange kein Projekt von selbst :-) Entwicklung ist Kunst, sonst bräuchte man keine Entwickler.
> Für viele Dinge gibts ja handwerkliche Methoden, quasi 'Idiome': Der > Aufruf von select() auf Unix folgt beispielsweise i.d.R. einem gängigen > Schema, das sich auch im Quelltext wiederfindet. Genauso der Aufbau von > QT-Programmen oder von Programmen überhaupt (main(), getopt(), ...). Und jetzt sind wir genau beim Thema: Wie eigne ich mir dieses Wissen an? Wie baue ich eine gute SW (Rezepte, Vorgehen, Verfahren). Und sage jetzt nicht, dass man dafür jahrelang probieren muss oder tausend verstreute Sourcen durchstöbern muss, um von selbst drauf zu kommen... ;-) > QS gibts in der SW genauso wie in der HW. [...] 'vermeide gets()' Auch wenns vielleicht abgedroschen ist: Ich will kein Faktenwissen, sondern Methodenwissen. > Aber du wirst jetzt keine Checkliste finden, mit der du ein Projekt > erledigst, Genau das suche ich aber (auch; bin ja nicht der Threadstarter). Naja, vielleicht nicht gleich ein Projekt, sondern ein (Teil-)Problem und auch auf etwas höherer Ebene, aber nicht abstrakt. > Entwicklung ist Kunst, sonst bräuchte man keine Entwickler. Entwicklung sollte Handwerk sein (damit ich mich auf das wirkliche Problem konzentrieren kann, nicht darauf WIE ich mein Problem am besten organisiere) - ich wiederhole mich. Aber vielleicht sind auch die Grenzen fließend. :-) Vielleicht können wir uns so einigen: Der Algorithmus ist Kunst, die Verwendung dessen sollte Handwerk sein.
Rainer schrieb: >> Für viele Dinge gibts ja handwerkliche Methoden, quasi 'Idiome': Der >> Aufruf von select() auf Unix folgt beispielsweise i.d.R. einem gängigen >> Schema, das sich auch im Quelltext wiederfindet. Genauso der Aufbau von >> QT-Programmen oder von Programmen überhaupt (main(), getopt(), ...). > Und jetzt sind wir genau beim Thema: Wie eigne ich mir dieses Wissen an? In den allermeisten Fällen hat sich irgendjemand das mal ausgedacht und andere fanden es akzeptabel bis gut. Aneignen tustes dir, wie in der Elektrik auch: Bestehende Anlagen und Schaltungen (Programme) anschauen, Anweisungen und Beispiele der Hersteller (Autoren der Bibliothek) befolgen. >> QS gibts in der SW genauso wie in der HW. [...] 'vermeide gets()' > Auch wenns vielleicht abgedroschen ist: Ich will kein Faktenwissen, > sondern Methodenwissen. > >> Aber du wirst jetzt keine Checkliste finden, mit der du ein Projekt >> erledigst, > Genau das suche ich aber (auch; bin ja nicht der Threadstarter). Naja, > vielleicht nicht gleich ein Projekt, sondern ein (Teil-)Problem und auch > auf etwas höherer Ebene, aber nicht abstrakt. Was erwartest du? Sowas? 1. Ziel festlegen 2. Module festlegen und verteilen 3. Kapseln und Reviews machen 4. Zusammenbauen >> Entwicklung ist Kunst, sonst bräuchte man keine Entwickler. > Entwicklung sollte Handwerk sein (damit ich mich auf das wirkliche > Problem konzentrieren kann, nicht darauf WIE ich mein Problem am besten > organisiere) - ich wiederhole mich. Aber vielleicht sind auch die > Grenzen fließend. :-) > > Vielleicht können wir uns so einigen: Der Algorithmus ist Kunst, die > Verwendung dessen sollte Handwerk sein. Joa, aber es gibt nicht den Algorithmus. Natürlich bringt man irgendwann man den 'stinknormalen' Aufbau eines Programms (main, getopt..) flux von der Hand oder beschaltet einen NE555 aus dem Kopf und wählt den LM2575. Da gibts etliche kleine Algorithmen, beim LM2575 stehen die sogar im Datenblatt.
> Was erwartest du? Sowas? > 1. Ziel festlegen > 2. Module festlegen und verteilen > 3. Kapseln und Reviews machen > 4. Zusammenbauen Nein, das ist das was man in all den "tollen" Büchern findet: viel Prozessbeschreibung, aber immer ist ausgespart, wie man das Design konkret (gerne auch mit Enten oder Hundehütten) umsetzt. Wie organisiere ich meine Daten (was gehört in diese Klasse, was gehört besser in eine eigene Klasse; wann vererben, wann komponieren...)? Welche Sprachmittel bieten sich an? Was hat sich in der Praxis als gut erwiesen? Warum macht man das nicht anders? Aber stattdessen viele Worte um testgetriebene Entwicklung, agile Arbeitsweise, Stakeholder und das ganze Zeugs. (Mag auch seine Berechtigung haben, aber ist nicht das was wir hier suchen). > Natürlich bringt man irgendwann man den 'stinknormalen' Aufbau eines > Programms (main, getopt..) flux von der Hand Ich möchte das "irgendwann" vorziehen, offenbar weiss schon jemand, dass man das so macht... das dann gesammelt, aufbereitet und runtergeschrieben -> perfekt. :-) Beispiel: In tausend C#-Büchern kriege ich erklärt was ein Button, eine Picturebox oder ein UserControl ist. Aber keiner (außer z.B. Petzold) erzählt mir, dass ich grundsätzlich im Paint-Event meine Ausgaben zeichnen muss, um nicht bei Fensterüberlappungen den Inhalt zu verlieren... Das sind die Dinge, die ich zusätzlich wissen muss(!). Umgemünzt auf die OO-Kiste: Tausend Autoren erklären mir was eine Klasse, Methode und ein Event ist, aber wann und wie ich ein Event nutzbringend anwenden kann, das wird (wenn überhaupt) nur sehr dünn behandelt. Hier setzen dann z.B. Entwurfsmuterbücher (z.B. MVC + Observer) an. Aber wenn man das nicht irgendwann rausfindet, gelitten. Einen Hinweis in den Grundlagenbüchern wo/wie es tiefer geht gibts nicht.
Rainer schrieb: > Beispiel: In tausend C#-Büchern kriege ich erklärt was ein Button, eine > Picturebox oder ein UserControl ist. Aber keiner (außer z.B. Petzold) > erzählt mir, dass ich grundsätzlich im Paint-Event meine Ausgaben > zeichnen muss, um nicht bei Fensterüberlappungen den Inhalt zu > verlieren... Das sind die Dinge, die ich zusätzlich wissen muss(!). Ja, deshalb stehen solche Dinge auch mit absoluter Sicherheit in der Dokumentation zur API, zum Framework, zu XYZ. Bei X11 steht das mit dem Neuzeichnen z.B. lang und breit in der Doku unter 'XExposeEvent' im XLib Reference Manual. > Umgemünzt auf die OO-Kiste: Tausend Autoren erklären mir was eine > Klasse, Methode und ein Event ist, aber wann und wie ich ein Event > nutzbringend anwenden kann, das wird (wenn überhaupt) nur sehr dünn > behandelt. Weil es sich kaum behandeln lässt -- guck mal in die Extrema: Java z.B.; da wird alles auf Teufel-komm-raus in Objekte verpackt, das hat man halt als 'Entwurfsmuster' so ausgelegt. Resultat ist dann, dass man für jede simple Aufgabe sofort dies und jenes in irgendwelche Klassen verpacken muss, wobei man am besten noch Interfaces umsetzt muss und dann 9 von 10 Prozeduren nur leere Platzhalter sind usw. Andres Extremum: GLib und GTK+. Dort benutzt man C (struktural, sprachlich NICHT objektorientiert i.S.v. 'Klassen'). Dadurch muss man zwar nicht alles in Objekte verpacken, aber dafür gibts dann so Dinger wie: * g_bookmark_file_load_from_data_dirs und * g_main_context_find_source_by_funcs_user_data und * g_win32_get_package_installation_directory_of_module und * gtk_color_selection_set_change_palette_with_screen_hook * GtkColorSelectionChangePaletteWithScreenFunc Will sagen: Es gibt keine goldenen Regeln dafür. Bestenfalls solche wie 'Klassenvariablen sind privat und gekapselt'. Was du wie und warum aufteilst, hängt in jedem Fall von deiner Anwendung ab! Das meinte ich ja weiter oben: Es kommt durchaus vor, dass du von Zeit zu Zeit mal ne ganze Reihe deiner Konzepte/Klassen/... über den Haufen wirfst und neu anfängst.
Ich hab mir vor kurzem auch C# selber beigebracht (C und C++ kenntniss waren bereits vorhanden) und hatte mit folgendem tutorial angefangen: http://openbook.galileocomputing.de/csharp/ Es macht schon sinn sich sowas im schnelldurchlauf mal durchzulesen damit man weis was fuer moeglichkeiten es gibt. damit man weis wonach mal "googlen" muss sobalt man an ein Problem kommt. ;-) Ich wuerde jedoch nicht ein ganzes Buch mit beispielen durcharbeiten, da ist man ewig mit beschaefftigt und 95% der sachen die man gelernt hat brauch man fuer das aktuelle projekt garnicht und 90% wird man niemals brauchen oder hat es vergessen bis man es mal braucht. daher meine empfehlung, les ein kurzes tutorial im schnelldurchlauf und dann fang mit einem sinnvollen projekt an. Da lernt man viel mehr und es bleibt einem auch laenger im Gedaechnis. eine Seite die mir sehr geholfen hat ist: http://www.codeproject.com/?cat=3
Bitte 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.