www.mikrocontroller.net

Forum: PC-Programmierung Pc Software richtig erstellen


Autor: C#möchtegern (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rainer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Mark Brandis (markbrandis)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 
;-)

Autor: C#möchtegern (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: C#möchtegern (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gruß Sven

Natürlich

Autor: Rainer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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-Vi... 
und das Update auf .net 2.0: 
http://www.amazon.de/Windows-Forms-Programmierung-...

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Rainer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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).

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Rainer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Rainer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Chris S. (hondaracer1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.