Zitat von
Go2EITS:
@fwsp
Das wollte ich nicht. Doppelter Code vergroßert unnötig die EXE.
Zitat von
Go2EITS:
Zitat:
procedure MachIrgendwas(Sender :TObject);
in der formCreate dann
Timer1.OnTimer := MachIrgendwas;
Grins... So kann man es auch machen.
Äh, wo siehst du denn hier den Unterschied? Du hast in beiden Fällen die eigentliche Abarbeitung ausgelagert. Einmal verwendest du noch einen Methodenzeiger auf die Prozedur, aber da hatte fwsp sich ja nicht festgelegt.
Nebenbei hat auslagern nichts mit doppelten Code zu tun! Doppelter (gleicher) Code wäre tatsächlich völlig unangebracht. Aber auslagern heißt nur, dass du für die Lösung eines Problems eine Methode verwendest. Typischerweise lagert man Code aus, um ebend doppelten Code zu vermeiden.
Das deine Exe um ein paar Byte größer wird und du auch noch ein paar nanosekunden für den Aufruf der Prozedur verlierst, wirst du kaum merken!
Und ich bin der Meinung, da die Routinen im Timer genau so abzuarbeiten sind, halte ich, nur um sauber zu arbeiten, eine Auslagerung der Routinen nicht für sinnvoll. Der Timer wird nur einmalig aufgerufen, ist währenddessen nicht aktiv und läuft dann "normal". Igendwelche Seiteneffekte oder undefinierte Programmzustände sind in meinem Fall ausgeschlossen.
Zitat von
Go2EITS:
Und ich bin der Meinung, da die Routinen im Timer genau so abzuarbeiten sind, halte ich, nur um sauber zu arbeiten, eine Auslagerung der Routinen nicht für sinnvoll. Der Timer wird nur einmalig aufgerufen, ist währenddessen nicht aktiv und läuft dann "normal". Igendwelche Seiteneffekte oder undefinierte Programmzustände sind in meinem Fall ausgeschlossen.
Wow, du hast keine Ahnung wovon du da redest, oder? Warum genau hälst du bitte die Auslagerung von Routinen nicht für sinnvoll? Und wie kommst du auf die Idee, dass du Seiteneffekte oder undefinierte Programmzustände ausschließen könntest?
Möchtest du Seiteneffekte ausschließen, dann solltest du funktional Programmieren. Schau dir mal sowas wie Haskell an, da gibt es dann auch die Lazy-Evaluation. Die ist immer ein eindeutiges Zeichen dafür, dass es keine Seiteneffekte (eben auch keine Zustände) geben kann. Da du aber imperativ bis Objekt Orientiert arbeitest, existieren Zustände, ergo sind Seiteneffekte durchaus möglich.
Ob sie (ungewollt) auftreten oder nicht ist dann so eine Sache, genau wie undefinierte Programmzustände hat das aber wenig damit zu tun, wie du hier die Methode aufrufst.
Das Timer1 weder ein Routinen noch ein Methodenbezeichner ist, ist dir doch hoffentlich klar?!
Zitat von
Go2EITS:
@Daniel
Ihr seid erfahrener. Offen gesagt, meine Button1.click Aufrufe machten mir überhaupt keine Probleme
im Projekt Delphi Cleaner. Nicht ein einziger Fehler/BUG war darauf zurückzuführen. Für mich zählt Praxis, nicht Theorie. Das Einzige was mich wunderte, war ein dass ein Checkbox1.checked:=StrToBool(h); die Checkbox1.click Methode aufgerufen hat... Aber das ist eine andere Frage.
Was möchtest du nun wiederum damit sagen. Sicherlich ist Daniel erfahrener als du (sorry, aber das merkt man einfach schnell). Schön dass du das anerkennst, aber warum genau ignorierst du dann was er zu sagen hat? (gilt auch für die anderen Beiträge). Du hast in irgendeinem Projekt nicht einen Fehler/BUG auf Button1.click zurückführen können, toll! Wieviele waren auf Button2.Click zurück zu führen?
Weißt du, ein paar wichtige Ziele gibt es für jede Software, da wären unter anderem immer Robustheit, Sicherheit, Erweiterbarkeit und Wartbarkeit (und noch viele viele mehr). Nehmen wir mal die letzten beiden, Erweiterbarkeit und Wartbarkeit haben viel miteinander gemeinsam. Sagen wir der Delphi Cleaner (was auch immer der kann) wird super erfolgreich und muss erweitert werden. Wer ausser dir wird denn jetzt wissen was Button1.Click macht? Klar, die Anwendung hat vielleicht nur einen Button, aber was ist wenn die 5 hat? Was genau ist dann die Aussage davon, dass Button1 gedrückt wurde? Nebenbei bemerkt wenn du 5 Button in einem Programm hast, dann wirst du in einem halben Jahr auch nicht mehr wissen, welcher Button was machte.
Das der Code funktioniert, das ist nicht die Frage/das Ziel. Du hast sicherlich schon etwas von QuickAndDirty gehört. Man findet immer wieder Leute, die so arbeiten, aber kaum in großen Firmen. Wenn du einen Kunden hast, der ein paar Ansprüche stellt, dann kommst du damit nicht weit. Die Bedürfnisse des Kunden sind in der Regel unscharf (zu Beginn eines Projektes), es gibt das Problem der Kommunikation (was will er wirklich, wie will er es, was will er nicht, ...). Die Entwicklung ist ein agiler Prozess, wenn dein Kunde dein Produkt sieht (einen Zwischenstand), dann kann der noch leicht Änderungswünsche einbringen. Da ist es dann sehr viel einfacher, wenn du die Logik schön ausgelagert hast und alles so benannt ist, dass jeder weiß welche Funktion was tut (und welcher Button wofür zuständig ist). Solltest du mit mehr als einer Person am Projekt arbeiten, ist anders keine Arbeit möglich. Aber auch wenn du allein an einem solchen Projekt sitzt, dadurch dass die einzelnen Problemlösungen ausgelagert sind, musst du kein Copy&Paste anwenden (was sehr fehleranfällig ist) wenn du hier einen Teil änderst.
Nicht zuletzt solltest du auch die
GUI von dem Rest trennen, denn gerade das Design ändert sich häufiger als der gesamte Rest.
Natürlich läuft auch jede andere Lösung, aber Änderungswünsche änden schnell in einem Chaos und keine Firma ist bereit sich ewig an einen Entwickler zu binden (weil ausser ihm nie jmd. durch den Code steigen wird).
Gruß Der Unwissende
(Roter Kasten, nur kurz Daniel's Beitrag überflogen, sieht aber nach der gleichen Richtung wie dieser Beitrag aus, wenn auch etwas ausführlicher und schöner von Daniel)