Hallo, ich habe in meinem Programm einige Fenster in denen sich etliche Methods befinden. Inzwischen sind das so viele, daß ich mehr scrolle und suche, als programmiere. Ist es irgendwie möglich die Methods in unterschiedlichen Ordnern (Grafik, Daten, Kommunikation, etc.) unter zu bringen, um die Sucherei zu verkürzen?
Man kann im Projekt Ordner anlegen und dort Fenster rein schieben.
Wenn sich Methoden wiederholen nutze ein Modul oder Klassen.
Mann kann auch unter einem Modul Klassen unterbringen und hat so einen Namespace (Namensraum).
Über der Baumansicht ist auch eine nützliche Suche.
Bookmarks sind auch nützlich oder #Pragma Warning ToDo
Ereignisse kann man nicht in Ordner unterbringen oder verschieben.
Als Beispiel wie man den Code verlagert in einem Click Ereignis
dieses .Speichern ist schön in der Klasse und kann so wieder verwendet werden.
Sub Action() Handles Action
Var c As New Class1
c.Speichern
End Sub
Ja, ich habe mir so beholfen, daß ich alle weiteren Methoden gleich in unterschiedliche Module schreibe. Allerdings ist das ziemlich umständilch. Einfach so verschieben geht garnicht, da die Methoden zu bestimmten Fenstern gehören. Dann müssen alle Variablen wieder global deklariert werden, da Module nur global deklariert werden können. Oder habe ich da irgendwas übersehen?
Das Xojo nur einzelne Methoden anzeigt ist nervig.
Da gab es schon Verbesserungsvorschläge über das Feedback Tool.
Variablen (Propertys) besser in eine Klasse tun sonst haste das Problem das Du nicht zwei gleiche Fenster auf machen kannst.
Ich sortiere Methoden einem Aufgaben Bereich zu welcher dann eine Klasse ist.
Das reicht mir um zu wissen wo was steckt.
Über Kontextmenü kann man auch schnell von Methode zu Methode springen ohne zu suchen.
Oberste Priorität sollte sein Methoden wieder zu verwenden um Copy/Paste zu vermeiden.
Wie genau meinst Du das denn?
wie oben im Beispiel rechte Maus auf .Speichern
dann kann man mit Menu “Go To Class1.Speichern” direkt hin springen.
Das ist ein typischer “Code Smell”. Du solltest Dir überlegen, wo und wie Dein Code ausgeführt wird.
Eine Model-View-Controller-Architektur würde bestimmt helfen. Oder Model-View, weil in Controller IMO in Xojo nicht benötigt wird. Dein Fenster sollte nur für die Anzeige verantwortlich sein. Alles andere wird über das Model gesteuert, was dann die einzelnen Klassen oder Klassengruppen anspricht. Und nein, dafür werden keine Globals benötigt.
Das überlege ich immer vorher. Habe mich für eine übersichtliche Frontend-Backend-Hardware Architektur entschieden. Der Code wird in Modulen ausgeführt, was aber an der zunehmenden Fülle immer unübersichtlicher wird.
Ich stelle keine Software her, sondern Apparate, deren Funktionen und Anwendungen im Laufe der Jahre immer komplizierter werden. Somit wird auch die Xojo-App ständig erweitert (und die Module immer voller). Also bleibt nur das schrittweise umschreiben in neue Unter-Module. Verschieben in Ordner wäre einfacher…
Auch das ist ein Code Smell.
1 Like
Danke, hilft weiter…
Mit der Struktur ist es ähnlich wie mit Kommentaren, je besser der Code strukturiert und verständlich geschrieben ist, desto weniger muss kommentiert werden.
M. E. nach solltest du dir Gedanken über Klassen und deren Funktionalität machen. Alles in Module oder Ordner zu verschieben ist keine Lösung, die auf Dauer Ordnung schafft.
Ohjee, wie es aussieht muß ich mir also irgendwann mal Gedanken über eine “Neuprogrammierung” machen.
Und dabei wollte ich nur die unterschiedlichen Module sortieren…
So ist das mit der Programmierung. Wenn Du noch nicht mit Patterns zu tun hattest, gibt es da ein ganz tolles Buch “Head First Design Patterns”. Auf meiner Webseite unter www.mothsoftware.com habe ich den Java Code in Xojo nachprogrammiert. Selbst wenn Du nur ein paar Patterns implementierst, dann wird das Deinen Code verbessern.
Parsen von Emails in das Kernstück von meinem Programm. Die ersten beiden Implementationen waren nicht sehr gut. Immer, wenn ich einen Bug beheben mußte, hatte ich zwei Gedanken: “oh, Gott, was hat der Code da noch einmal gemacht” und “hoffentlich gibt die Änderung nicht irgendeinen Nebeneffekt”. Seit einigen Jahren gibt es nun 20-25 Klassen statt einer einzigen. Und wenn ich einen Bug finde, dann habe ich das Vertrauen, daß ich den Bug einfach finden und lösen kann, ohne daß ich etwas kaputt mache.
1 Like