Module - Ja oder Nein?

  • Allgemein

Es gibt 45 Antworten in diesem Thema. Der letzte Beitrag () ist von ErfinderDesRades.

    Module - Ja oder Nein?

    Hey Community,

    ich habe nochmal ein paar Fragen, damit mein jetziges Projekt auch sauber gecodet und aufgeräumt wird.
    Vorab: Ich code momentan Conway's Game Of Life auf eine sehr ausführliche Weise, und da sind jetzt schon einige Zeilen Code zusammengekommen:

    1. Da ich sowohl viel im eigenen Control passiert, als auch auf der Form, habe ich die relevanten Variablen in ein Modul 'Settings' ausgelagert, bzw. sie dort als Properties eingerichtet. Sind Module noch 'uptodate' ^^ ?
    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 ?
    »There's no need to "teach" atheism. It's the natural result of education without indoctrination.« — Ricky Gervais

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „ThePlexian“ ()

    Hi
    da gehen mW. die Meinungen hier im Forum auseinander. Das Modul dient als Ersatz für bzw. als statische Klasse selbst in VB. Es gibt ja keinen statischen Modifikator für die Klasse, wie in C#.
    Andererseits haben Module die Eigenschaft, dass alle Member global zugänglich sind, ohne den Kontext zu spezifizieren, sobald deren enthaltender Namensraum zugänglich ist. Wenn du also auf einen Member des Moduls zugreifen möchtest, musst du den Modulnamen selbst nicht schreiben, sondern kannst direkt auf den Member zugreifen. Meiner Meinung nach ist das ein gewaltiger Nachteil, weil damit die Einordnung in den semantischen Kontext nicht durch die Klasse (bzw. durch das Modul) eindeutig festgelegt wird, sondern direkt im Modulmember enthalten sein müsste, wo er aber mMn. nichts zu suchen hat. Daher verwende ich folgendes Konstrukt, verweise aber explizit darauf, dass es durchaus auch anders richtig sein kann:

    VB.NET-Quellcode

    1. Public NotInheritable Class StaticClass
    2. Private Sub New()
    3. End Sub
    5. 'Deklaration statischer Mitglieder
    6. End Class

    Bin mir gerade nicht sicher, ob es nach Microsoft-Konvention für nicht statische Klassen unterstützende CLI-Sprachen NotInheritable oder MustInherit sein müsste.

    Edit:
    Man sollte beides angeben: msdn.microsoft.com/en-us/libra…o/ms229038(v=vs.100).aspx
    Das geht in VB aber nicht (war damals btw. auch meine Idee, als ich noch kein C# konnte und keine Module in VB dafür verwenden wollte, daher ist das hängen geblieben). Hier btw. noch die lustige deutsche Übersetzung davon msdn.microsoft.com/de-de/libra…o/ms229038(v=vs.100).aspx, die genau das Gegenteil behauptet.

    Gruß
    ~blaze~

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von „~blaze~“ ()

    So wie blaze es vorschlägt halte ich es mittlerweile auch. Hatte dazu selbst noch kürzlich einen Thread veröffentlicht ob meine angedachte Vorgehensweise die "korrekte" ist.

    Nichtsdestotrotz kommt man um Module in VB nicht herum, wenn man Erweiterungsfunktionen nutzen möchte. Die sind in VB ausschließlich in Modulen erlaubt.
    Weltherrschaft erlangen: 1%
    Ist dein Problem erledigt? -> Dann markiere das Thema bitte entsprechend.
    Waren Beiträge dieser Diskussion dabei hilfreich? -> Dann klick dort jeweils auf den Hilfreich-Button.
    Danke.

    @~blaze~:: Na gut, also eine ganz normale Klasse in der einfach alle Member Static (in VB Shared) sind. Aber warum NotInheritable ? Wer sollte schon davon erben ? :D

    @VB1963:: Ich nutze die My.Settings schon, aber während der Laufzeit hast du deine Variablen doch wohl auch normal deklariert als in den Settings oder ? ^^

    @All: Bitte schaut euch auch nochmal die anderen Fragen an :)
    »There's no need to "teach" atheism. It's the natural result of education without indoctrination.« — Ricky Gervais

    Ich finde schon der Bedarf, irgendwelche Properties woanders hinzuverlagern zeigt, dass deine Struktur nicht durchdacht ist. Es kommt einfach kein Code in die Form, und auch nicht in irgend ein anderes Control, dann musst du auch nicht darauf zugreifen. Ich würde da so vorgehen, dass das Spiel erstmal komplett ohne GUI, also ausschließlich in Form von Daten funktioniert. Wenn das fertig ist, setzt man da ne GUI drüber.

    ThePlexian schrieb:

    Ist es möglich, in dem Setter einer Property des Settings-Moduls auf die Controls der Hauptform zuzugreifen und diese auch zu bearbeiten ?

    Wenn du Einstellungen von Controls meinst - schaue in den 2. Link von mir oben...
    Wenn ich Settings verwende und sie in Variablen verarbeite, dann nicht in einem Modul.

    Artentus schrieb:

    Ich finde schon der Bedarf, irgendwelche Properties woanders hinzuverlagern zeigt, dass deine Struktur nicht durchdacht ist.

    Bitte was ? Ich nutze halt diese Form, weil ich die Variablen in mehreren Klassen brauche.
    »There's no need to "teach" atheism. It's the natural result of education without indoctrination.« — Ricky Gervais

    Würdest du ordentlich mit Objekten arbeiten, dann müsstest du sowas trotzdem nicht machen, weil sich die jeweiligen Objekte dann halt gegenseitig kennen und die Eigenschaften deswegen ganz einfach abfragen können.
    Bei Game of Life ist es aber gar nicht so schwierig, du brauchst ja eigentlich bloß ein 2D-Bool-Array, das die Zellen darstellt, und nen Thread/Timer, der regelmäßig das Feld updatet, das lässt sich alles in einer Klasse ausdrücken. In der Form reagierst du dann nur auf ein Update des Feld-Zustandes und zeichnest entsprechend.

    @Artentus::
    Ich hab das ja alles schon, das hat ja alles funktioniert bei mir, nur wollte ich es übersichtlicher gestalten und nicht alles in eine Klasse stopfen.
    Also habe ich ein Control für das Feld, welches einige Aufgaben übernimmt.
    Aber wie realisiere ich das? :

    Artentus schrieb:

    weil sich die jeweiligen Objekte dann halt gegenseitig kennen und die Eigenschaften deswegen ganz einfach abfragen können.
    »There's no need to "teach" atheism. It's the natural result of education without indoctrination.« — Ricky Gervais

    Also bei diesem Spiel hält sicher der Code doch sehr stark in Grenzen. Dass kein Bedarf besteht, alles in extra Klassen aufzuteilen, siehst du daran, dass du keine weitere Einteilung unter dem Spielfeld durchführen kannst (außer Zelle, aber da die mit nem bool schon vollständig beschrieben ist, wäre ne Klasse dafür sinnlos und Ressourcenverschwendung). Du hast einfach eine Klasse "Map", die hat die Funktionen "Start" und "Stop", um das Spiel zu starten, die Eigenschaft "Cell" um den Zustand einer Zelle abzufragen oder festzulegen, und vielleicht noch ne Eigenschaft "GameSpeed", die die Geschwindigkeit des Spiels angibt. Zusätzlich braucht die Klasse noch ein Event "StateChanged", das ausgelöst wird, wenn das Spielfeld geupdatet wurde. Die Form reagiert auf dieses Event und zeichnet einfach anhand der "Cell"-Eigenschaft die Zellen, "Start" und "Stop" können mit Buttons verknüpft werden und wenn das Spiel gerade nicht läuft, setzt du im Maus-Down ebenfalls über die "Cell"-Eigenschaft die entsprechende Zelle.

    Artentus schrieb:

    Du hast einfach eine Klasse "Map", die hat die Funktionen "Start" und "Stop", um das Spiel zu starten, die Eigenschaft "Cell" um den Zustand einer Zelle abzufragen oder festzulegen, und vielleicht noch ne Eigenschaft "GameSpeed", die die Geschwindigkeit des Spiels angibt. Zusätzlich braucht die Klasse noch ein Event "StateChanged", das ausgelöst wird, wenn das Spielfeld geupdatet wurde. Die Form reagiert auf dieses Event und zeichnet einfach anhand der "Cell"-Eigenschaft die Zellen, "Start" und "Stop" können mit Buttons verknüpft werden und wenn das Spiel gerade nicht läuft, setzt du im Maus-Down ebenfalls über die "Cell"-Eigenschaft die entsprechende Zelle.

    Hab ich schon aaaaaaaaaaaaaaaalles ^^ Nur habe ich halt nicht nur die Klasse Map sondern das auf ein Control erweitert, und die Animation ist eine extra Klasse. Nur wollte ich diese extra Klasse für die Animation auch Static machen, sowie halt meine ganzen Einstellungen (Zellen, Spielfeldgröße, Generation, Aktuell Lebende / Gesamte Anzahl Zellen, die Regeln, der Mapstyle und und und ^^)
    »There's no need to "teach" atheism. It's the natural result of education without indoctrination.« — Ricky Gervais

    Spielfeldgröße wäre bei "Map" im Konstruktor zu übergeben. Generation und Anzahl lebender Zellen sind ebenfalls Dinge, die in "Map" gespeichert werden sollten, das wären dann Readonly-Eigenschaften.
    Was man bei dem Spiel für Aninationen brauchen könnte, kann ich mir aber nicht vorstellen.

    Aber es funktioniert ja so wie ich es habe... Und btw, Animation nur, weil halt die GEnerationen durchiterieren.

    Können wir zu meinen Fragen zurückkommen ? ^^

    "ThePlexian" schrieb:

    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 ?
    »There's no need to "teach" atheism. It's the natural result of education without indoctrination.« — Ricky Gervais

    Mach was du willst, aber ich werde keine OOP-widrigen Systeme für dich flicken.

    3. Ja, siehe OOP. Das wäre allerdings eher ne Eigenschaft auf Map oder so, auf jeden Fall muss das direkt mit Map verknüpft sein.
    4. Namespaces ordnen semantisch zusammengehörige Typen. Ob und wie das bei dir der Fall ist, musst du selbst wissen.
    5. Wenn du Prüfung auf Wertegleichheit meinst, nein, Referenzgleichheit funktioniert ganz normal.
    6. "Reset" setzt auf den Urzustand, das andere wäre "Abbrechen".

    @Artentus:: Gut ich danke dir, ich werde dann den Code ändern, wenn er wirklich nicht OOP ist auch wenn mir der Grund noch nicht ganz klar ist :)
    »There's no need to "teach" atheism. It's the natural result of education without indoctrination.« — Ricky Gervais