Module - Ja oder Nein?

2. Meine HauptForm heißt "MainForm". Ist es möglich, in dem Setter einer Property des Settings-Moduls auf die Controls der Hauptform zuzugreifen und diese auch zu bearbeiten ?
3. Die Animation habe ich ebenfalls in ein Modul ausgelagert, um im Haputprogramm einfach Animation.Start() schreiben zu können. Ist das gut, oder sollte ich lieber eine normale Klasse nehmen und die instanziieren ?
4. Im Projektmappen-Explorer habe ich einige Sachen mittlerweile: 4 Formen, 3 Controls und 2 Module, sollte ich die iwie mit Namespaces kategoriesieren oder einfach lassen ?
5. Gibt es eine Möglichkeit zwei 2-dim-Arrays auf Gleichheit zu prüfen ? Momentan nutze ich noch meine eigene Sub().
6. Wenn ihr eine SettingsForm seht und der Reset Button vorhanden ist, erwartet ihr dann das beim Klick die Settings auf den kompletten Urzustand zurückgesetzt werden oder dass sie nur auf den Zusatand zurückgesetzt werden, den sie beim Öffnen der Form hatten ?

1. -
   
2. möglich ist alles - das wär nur gräuselig. Ein Modul ist eine Hilfs-Klasse, also die Objekte bedienen sich der Module - nicht annersrum
   gugge auch VeryBasics
   
   
3. prinzipiell ist das möglich, und kann auch gut sein. Nur: Auslagern tut man nur solche Dinge, die man mehrfach verwendet. Nur auslagern, dass ausgelagert ist, macht Code unnötig unübersichtlich.
   Man kann auch auslagern, um den Level of Abstraction gleich zu halten - guck einfach bei CleanCodeDeveloper, ich hab den korrekten Namen dieses Prinzips vergessen.
   
   
4. mach wie du willst, oder besser noch: kümmer dich erst darum, wenn die Unübersichtlichkeit sich wirklich störend bemerkbar macht. Auch hier ist das Prinzip KISS anzuwenden: Keine Probleme lösen, die noch garnet aufgetreten sind - siehe CleanCodeDeveloper
   
   
5. vermutlich willst du die Werte vergleichen. Ein listiger Trick wäre:

   VB.NET-Quellcode

   1. Dim arr1 = {{2, 3, 4}, {4, 5, 6}}
   2. Dim arr2 = {{2, 3, 4}, {4, 5, 6}}
   3. Dim bb = arr1.Cast(Of Integer).SequenceEqual(arr2.Cast(Of Integer))
   beachte aber, dass hier die Dimensionalität unberücksichtigt bleibt, also
   {{2, 3, 4}, {4, 5, 6}}.Cast(Of Integer).SequenceEqual({2, 3, 4, 4, 5, 6}) ergibt auch True
   
   
6. Standard sind Ok-Button und Cancel-Button, und da weiß jeder, was da passiert. "Reset to Default-Values" ist kein Standard
   

@ThePlexian:
Noch etwas Zusätzliches. Ich denke du willst ein zweidimensionales Array benutzen um deine Felder darzustellen.
Im Prinzip kein Thema, aber ich finde eindimensionales handlicher.
Außerdem sind sie sehr einfach zu benutzen, wenn man weiß wie.
Hier ist ein Beispiel.



Wenn du die Position im Array und die Breite kennst, dann kannst du die x- und y-Koordinate einfach über
x = Stelle %(Mod) breite und
y = Stelle \ breite
abrufen.

LaMiy schrieb:

x = Stelle %(Mod) breite und
y = Stelle \ breite

Kleiner Trick dafür, wenn mans wirklich so machen will:

Das Control kannst du auch ruhig behalten, ist ja dann mehr oder weniger der sichtbare Aufsatz über den Daten.

Auf jeden Fall besser. Ich kenn ja den Code nicht, vielleicht würde ich einiges etwas anders lösen. Aber ins Detail brauchen wir jetzt nicht gehen, schließlich will ich dir nicht meinen Programmierstil aufzwingen, zumal da eh schwer zwischen richtig und falsch unterschieden werden kann.

"Sauberer Code" - das ist das Thema der Site CleanCodeDeveloper - deswegen heissen die so, unds ist auch wirklich genial, was die verbreiten.
Übrigens musste bischen aufpassen, nicht dem Hang zu verboser programmierung zu erliegen: also tw. viel zu wortreich und alles mögliche mit abdeckend, was grad aber garnet gefragt ist.
Das ist nämlich nicht sauber.
Diesen Verbose-Effekt findet man bei vielen Proggern, die besonders bemüht sind, "sauber" zu proggen, bes. bei c#lern.

Wirklich: arbeite die CleanCodeDeveloper-Prinzipien durch, das sind so einige, und die werden da auch gut erklärt.
Und Augenmaß behalten: Eine Anwendung mit 3 Forms und bischen drumrum - da kannst du gerne den Löwenanteil einfach im CodeBehind abhandeln (jdfs. in WinForms).
Das ist in dem Fall sauberer, als sich eine 3-Schichten-Architektur aus den Rippen zu schneidern. Und sei sie auch noch so schön: Sie ist in dem Fall unsauber, weil Overkill.

Ahh ich fühle mich persönlich durch EDR angegriffen. Wir c#ler sind auf der bösen Seite, quasi konvertiert, vom engelsgleichen, gut aussehenden vb. Im Namen aller C#ler, es tut uns leid!

Artentus trifft es genau auf den Punkt. Wenn man deinen Beitrag liest, denkt man, okay, ist seine Meinung, aber dann kommt immer so ein unnötiger Kommentar Mal ehrlich, Generikas und Interfaces sind das schönste am programmieren

Ich werd da jegliche Diskussionen jetzt mal unterlassen.
Wenn du nicht höher abstrahieren willst, als notwendig, dann mach das so, aber lass uns halt unsere Spielereien, dabei lernt man nämlich so einiges.

@thucommix: versuchmal sachlich zu bleiben. gut und böse und die Engel - also davon ist hier sicher nicht die Rede.

@Artentus:: hey - das trifft ziemlich gut, was ich sagen wollte: Höher zu abstrahieren als nötig sollte man sehr kritisch ansehen

Aber mw. diskutieren wir das nicht weiter - ich habs ja nu gesagt.
Unds ist auch nicht das wichtigste, was ich rüberbringen wollte: CleanCodeDeveloper ist wichtig, wenn man sich für sauberen Code interessiert.

Ich bin zwar weder Freund von Interfaces noch von Generics, aber hier sollt man abwägen. Tu ich das Nötigste und halte meinen Code simpel, oder sorge ich für spätere Tage vor und halte das Ganze so abstrakt wie möglich um die Wartbarkeit zu maximieren.

Ich bin da für Zweiteres, halte alles schön abstrakt und strukturiert, sodass ich später (ohne die ganze Architektur über Bord zu werfen) problemlos Dinge erweitern kann

Gonger96 schrieb:

Tu ich das Nötigste und halte meinen Code simpel, oder sorge ich für spätere Tage vor

Das ist kein Gegensatz - eher im Gegenteil.
Simpler Code ist eine ausgezeichnete Grundlage, um später zu erweitern.
Und wenn ich irgendwas generisch programmieren kann statt mit konkreten Typen - na das nehm ich meist gerne mit - das macht mein Code ja nicht komplexer.

ErfinderDesRades schrieb:

Simpler Code ist eine ausgezeichnete Grundlage, um später zu erweitern.

Wenn die oberste Schicht so abstrakt ist, das in den unteren Schichten alles austauschbar ist - dann ist es doch eher leicht erweiterbar / wartbar. Findest du nicht?

nicht unbedingt. Verfrüht mit Abstraktion anzufangen kann auch in Strukturen führen, die später den Anforderungen gar nicht optimal gerecht werden.

Generika sind ne schöne Idee, nur die wurde schlecht umgesetzt. Das is aber wieder ne andere Geschichte, die tut hier nichts zur Sache.

Problem ist, dass bei etwas komplexeren Programmen dann das Problem auftritt, dass diese nicht erweiterbar sind. Zumindest nicht ohne das Konzept völlig zu ändern. Das ist mir schon ab und zu passiert, man muss dann einen enormen Aufwand reinstecken.

Schöner ists wenn man von Anfang an eine passende Architektur sucht. Die dann besser wartbar ist.

Dann hat man dabei etwas falsch gemacht...

Tut mir leid. In letzer Zeit sinkt meine Meinung von dir immer weiter @ErfinderDesRades. Es gibt einfach einen großen Unterschied zwischen overkill und sauberem Programmieren und Erweiterbarkeit.
Und gerade bei Projekten die nicht vollständig abgegrenzt sind (durch Projektauftrag im Bezug auf Ziele, Nebenziele und Nichtziele welche selbstverständlich alle SMART definiert sind) ist eine gewisse Erweiterbarkeit durchaus zu wünschen. Sorgt man in einem frühen Entwicklungsstadium für eine gewisse Erweiterbarkeit so ist man später wesentlich sauberer Unterwegs als wenn ich später irgendwie alles reinwürgen muss, teilweise neu schreiben muss und alles refactorn muss. Und das ist auch genau der Punkt wo äußerst viele Fehler entstehen und dir die ganze Applikation instabil werden kann und zu bröckeln beginnt.
Sich gegen Generika und Interfaces zu wehren ist einfach komplett schwachsinnig und unnötig, da diese enorme Vorteile mit sich bringen.
Und wenn das deine Meinung ist, dann mach du das so und beiße von mir aus ins Gras. Du kannst auch deinen Standpunkt klar machen und von mir aus Begründen (soweit dies bei deinem Standpunkt überhaupt möglich ist), jedoch solltest du nicht versuchen deinen Standpunkt als zwingend richtig darzustellen. Denn wie gesagt: Man kann Zeug programmieren das einfach nur overkill ist, jedoch hat das rein gar nichts mit einer schönen Architektur und einer gesunden Erweiterbarkeit zu tun.