Ich bräuchte mal etwas konstruktive Kritik

NRFi, das ist C#
Halte bitte unser nettes C# Forum von solchen polemischen VB Statments sauber.
Das kann man im NET Forum diskutieren!
ich hab nur auf den "wurstelcode" reagiert, das kann ich auch hier. und in den Fuß schießen tun sich Anfänger. Ansonsten ist es genauso einfach, mit VB OOP zu machen wie mit C#, wer das nicht kann, naja... hat entweder einen anderen Geschmack, oder sorry, hats nicht drauf (was ich ja nicht von dir glaub).
Mir gings nur darum, das mit dem Wurstelcode richtig zu stellen. ansonste geb ich broetchen recht, 3-schichtige Modelle reichen in der Regel aus.
Für kleine Anwendungen würd ich das aber auch nicht bevorzugen, auch wenn es da Vorteile hat.
 
Ansonsten ist es genauso einfach, mit VB OOP zu machen wie mit C#, wer das nicht kann, naja... hat entweder einen anderen Geschmack, oder sorry, hats nicht drauf.
Mir gings nur darum, das mit dem Wurstelcode richtig zu stellen.
Das streite ich doch auch nicht ab das man "OOP gerecht mit VB proggen kann".
Nur verleitet VB wie PHP zu diesem "Wurschtelcode". Darum gehts nur.
Glaubst Du ein Anfänger merkt in VB so schnell das er ohne OOP Kenntnisse
irrationalen Mist proggt der ansich Funktioniert, wohingegen aber bei C# aufeinmal Schluss ist?

Schluss jetzt, das wird jetzt einfach zu :offtopic:
 
Hallo Leute,
und da dies ja jetzt geklärt ist kommen wir mal hier zu:

das mit der Primzahlen Berechnung war nur ein Beispiel.
Also halten Wir mal fest:
1. Wir entwerfen uns ein oder mehrere From(s)
2. Wir erstellen für jede Form eine Klasse, in der oder den Klasse(n) kommen die Funktionen rein die z.B. beim Button_Click oder ListBox_SelectedIndexChanged u.s.w. ausgeführt werden und den globalen Variablen für die Form(s).
3. Eine Klasse mit allen zusätzlichen Funktionen und allen globalen Variablen die für das ganze Programm bestimmt sind.
4. Mit den Exception's habe ich jetzt noch keine Ahnung, aber Wir warten damal was Norbert so ausarbeitet. Danke nochmal, wäre echt cool wenn Du das machen würdest, Danke.
5. Eine Klasse für die Daten schreiben/lesen egal jetzt ob Datenbank, XML, Textdatei oder Rescourcedatei u.s.w.

Ich bitte um Verfolständigung, wenn jemand noch eine Idee hat!!
Bis Dann
 
Ich habe das Gefühl, dass du dir das Ganze etwas zu einfach vorstellst.
Es gibt beim Programmieren kein Schema F, nach dem du alles runter rattern kannst, und dann geht alles. Natürlich gibt es Teile von Programmen, die du immer wieder verwenden kannst, dafür entwirft man sich ja auch Komponenten, damit man nicht immer wieder alles von vorne coden muss, aber summa summarum ist jedes Programm anders.

Für jede Form plump eine neue Klasse zu entwerfen hat keinen Sinn. Es kommt eben ganz darauf an, was die Dinger machen.

Schnapp dir mal ein Buch, das sich mit Design Patterns beschäftigt.
Im Netz solltest du massenweise Infos zu MVC finden, das ist zwar Java, aber gilt in C# würde ich mal sagen genauso (zumindest vom Prinzip her).
:google: einfach mal ;-)

Und die Funktionen in deiner Bussines-Logik button1_Click() zu nennen, ist auch nicht wirklich sinnvoll. Man sollte klingende Namen verwenden (was .net meiner Meinung nach sehr gut macht), auch wenn das ein Problem ist. Ich habe auch meine Mühen damit, für jede Klasse und dessen Eigenschaften nen passenden Namen zu finden.

mfg broetchen
 
[Final :offtopic: ]
NRFi hat gesagt.:
see ya in vb-forum
Ha, ich glaube nicht. :p
Als ich einmal dort war, hat einer behauptet MD5 ist reversibel.
Mach doch einen Thread VB vs. C# im .NET-Forum auf. :suspekt:
(geflamed :D)

@Topic:
broetchen hat gesagt.:
Und die Funktionen in deiner Bussines-Logik button1_Click() zu nennen, ist auch nicht wirklich sinnvoll. Man sollte klingende Namen verwenden (was .net meiner Meinung nach sehr gut macht), auch wenn das ein Problem ist. Ich habe auch meine Mühen damit, für jede Klasse und dessen Eigenschaften nen passenden Namen zu finden.
Ganz genau, aber nicht nur "klingende" Namen verwenden,
sondern auch an die Namenskonventionen halten. Damit alles schön unterscheidbar ist. :)

@Reverent:
  1. Die wirst Du brauchen. :D
  2. Ich denke Du meinst jetzt eine Klasse die von Form erbt? Ja.
    (Wird doch sowieso erstellt wenn Du ein neues Form zu denem Projekt hinzufügst.)
    Und ja, die Objekte kommen da rein. Aber vielleicht bietet sich dafür wieder ein Container an,
    sofern meherere Objekte nur untereinde kommunizieren/gebraucht werden. Liegt in deinem Ermessen.
  3. Eine Klasse für einen Aufgabenbereich.
    Eventuell GrundWerte die im nachhinein nicht verändert werden in andere Klassen implementieren
    und davon erben lassen. ;)
  4. Ich hab Dir einen Hinweis dazu gepostet. Den kannst Bis dahin beherzigen. :)
    Schau mal in den Exception Thread im .NET.Fourm. ;)
  5. Wunderbar. :)

Weiter kann man es nicht spezifizieren. Dein Verständniss für die OOP entscheidet letztendlich,
wie Du das alles gestaltest.

MfG, cosmo
 
@Reverent

Sag mal, was du eigentlich machen willst. Vielleicht können wir dir bei deiner Architektur dann ein bisschen helfen. (Das soll nicht heißen, dass wir dir hier dein Programm entwerfen, also komm nicht auf dumme Gedanken ;-))

mfg broetchen
 
Mach aber mal bitte einen neuen Thread dafür auf.
Wir wollen diesen Thread nicht unnötig überladen. Ich denke hier ist alles soweit geklärt. :)
 
Zurück