Funktionen auslagern? (war: Einige allgemeine Fragen)

BeTZe

Hallo zusammen,

ich habe zwei kleine Projekte und ein großes Projekt vor mir. Mit dem BCB habe ich mich schon ein bischen beschäftigt. Jetzt habe ich mal ein paar allgemeine Fragen dazu:

- Ist es besser, einzelne Funktionen aus dem Hauptformular auszulagern??
- Wenn ja, womit macht man das am besten?? Nimmt man am besten ein neues Formular oder was anderes??

Danke im voraus
BeTZe

Edit:
Bitte aussagekräftige Überschriften wählen. Danke!

sorka

ich würd mir an deiner stelle selbstgeschriebene funktionen in eine extra cpp datei schreiben. dazu dann noch ne header-datei und fertig.
mit selbstgeschriebene funktionen mein ich aber nicht irgendwelche OnClick Ereignisse.
eher: void myfirstfunc(void){}
die mußt du aber in der "h"-datei deines Formulars deklarieren.
und natürlich in die cpp-datei deines formulars mußt du deine neue "h"-datei includen.

ich hoffe das war jetzt so richtig wie ich das erklärt hab.
weil ich mach das so seit msvc. so ist es einfach übersichtlicher.

junix

Ist es besser, einzelne Funktionen aus dem Hauptformular auszulagern??

Besser als was? Und was genau meinst du überhaupt damit? Memberfunktionen sind dort sinnvoll wo sie hingehören.

Empfehlenswert ist es auch mal ein Objektmodell aufzuzeichnen um eine Applikationsarchitektur zu erstellen...

-junix

Darkfalcon

Ich mache es genauso wie @sorka.
Alles was nicht direkt mit dem Formular zu tun hat wird in eine extra-Datei ausgelagert.
Ich nenne sie meisst Modul.cpp, Modul.h an Anlehnung an Visual Basic

junix hat die Frage doch schon erschöpfend beantwortet. Ich verwende schon seit Jahren keine globalen Funktionen mehr... Die gehören immer zu einem Form, Klasse... Und somit erübrigt sich die Frage wohin damit.

sorka

@Joe_M.
Also wenn man deinen post liest könnte man glatt ein schlechtes gewissen kriegen.
Aber wir reden hier von "globalen" Funktionen und nicht Variablen.
Also wüßte ich nicht warum ich nicht alle eigenen funktionen auslagern sollte.
Aber am ende entscheidet das ja sowieso jeder anders.
das zählt mit zum programmierstil.

@sorka: ja wir reden von globalen Funktionen. Mir fällt kein einziger Grund ein, sowas zu verwenden - nicht mal ein sinnvolles 'Ausnahmebeispiel'. Bitte laßt euch nicht von alten C-Büchern auf's Glatteis führen. C ist tot, es lebe C++.

VolkerH

Hallo,
es ist eine der größten Sünden beim Programmieren, Businessfunktionen und Präsentationen zu vermischen, leider führt der Builder mit seiner "Dirty Click"- Philosophie viele dazu und gerade im vcl- umfeld gibt es sehr viele solcher programme..

es gibt auch genügend vernünftige Methoden, die man global schreiben kann. neben wir eine Zinsberechnung, Rundungsfunktionen (z.B. Rundung auf 2 Cent genauigkeit), Konvertierungen, spezielle Datumsfunktionen (z.B. eine 360- Tage- Regel Differenz zweier Datumswerte)... auch der builder macht das übrigens, so hat jeder dbx- treiber in der dll eine globale funktion, die nach dem dynamischen laden der dll zugeordnet und aufgerufen wird, um eine konkrete instanz der abstrakten implementierung des treibers zu erzeugen, danach wird über die vcl nur noch mit der abstrakten klasse gearbeitet. da sich funktionen besser dynamisch zuordnen lassen, wäre alles andere auch irrsinn.

natürlich kann man globale methoden in Util- klassen packen, die ja nur statische Methoden enthalten, und daher ohne instanzierung aufgerufen werden können. für bestimmte berechnungen (wie Runden, Zins, Datum, ...) ist das auch richtig, da ich sie so inhaltlich noch einmal gruppieren kann (kann ich allerdings auch mit namensräumen. dann habe ich keine globalen funktionen, denn um zu runden, braucht man ja nun wirklich keine objektinstanz. also, keine instanz eines objektes bilden, und schon garnicht via copy and paste die rundung in jedes formular zu übertragen, dass ist ein guter ansatz einfache (oder sehr spezialisierte Methoden wie im Fall der Treiber) in globale funktionen zu übertragen.

zur vorgehensweise, prinzipchell kann man solche methode in eigenen cpp dateien implementieren und entsprechende header- datei fertigmachen. dabei muss nicht gelten, dass es zu jeder cpp- datei genau eine headerdatei geben muss, du kannst mehrere Implementierungsdateien in einer einzigen Headerdatei zusammenfassen, oder umgekehrt. wichtig ist nur, dass es in headerdateien zu allen methoden, die du in anderen modulen verwenden willst, entsprechende prototypen gibt.

wenn man die methoden exportiert, lassen sie sich dann auch gut in dll's packen, so dass sie in verschiedenen projekten zum einsatz kommen. dann wird die dll (bzw. die dazugehörige link-lib) dem projekt dazugegeben, die headerdateien im neuen Projekt verwenden, und du hast Wiederverwendung. Wenn Du diese Methoden alle in Formularen bereitstellst, dann ist eine Widerverwendung (ausser natürlich "copy and paste" recht schwierig).

@joe
"veraltete C- Bücher", warum glaubst Du wurden erst spät namensbereiche in C++ aufgenommen? bestimmt nicht, weil es obsolet ist. und schaue dir mal die algorithmen der STL an, auch dass sind prinzipchell globale funktionen.

Wie Du schon gesagt hast, gehört das dann in eine DLL.

Solche 'globalen Funktionen' sind dann aber auch grundsätzlich Projektunabhängig. Projektunabhängige Funktionen nur in einer CPP / Header-Datei unterzubringen führt bei Änderungen an diesen globalen Funktionen dazu, dass alle Projekte die sie verwenden neu kompiliert werden müssen...

Innerhalb nur eines Projektes sehe ich überhaupt keine Veranlassung globale Funktionen zu verwenden.

Edit: Selbst die von Dir genannten Beispiele (Runden, Datumsberechnung usw.) würde ich in einer eigenen Klasse kapseln.

Alexander Kempf

Joe_M. schrieb:

Edit: Selbst die von Dir genannten Beispiele (Runden, Datumsberechnung usw.) würde ich in einer eigenen Klasse kapseln.

Weshalb? Welchen Vorteil versprichst Du Dir davon?

Gruß,

Alexander

VolkerH

@joe
man sollte ein programm immer in schichten zerlegen, und klassen und funktionen sinnvoll in dll's auslagern, aber das ist ein anderes problem, es ist auch der zweite schritt, du willst aber den ersten nicht machen und sagst, es gäbe dafür keine notwendigkeit.

übrigens gibt es auch projektunabhängige klassen , die sollte man genauso auslagern, das ist also kein Problem der, wie du immer schreibst 'globalen Funktionen'. und warum nur in eine CPP/Header- Datei, die kann ganz schön groß werden, wir haben zig Dateien, auf die das zutrifft.

warum willst du für runden, ... eine eigene klasse? schau dir mal die stl an, ist wahrscheinlich deiner meinung nach schlecht implementiert. wenn eine normale klasse erzeugt wird, muss im speicher ein objekt erzeugt werden. das kostet einfach zeit und ist überflüssig. und dass nur, um eine methode (oder mehrere) zu implementieren, die keinen eigenen status und keine identität besitzt? dann bleibt wirklich die frage, warum wurden die namensräume in c++ eingeführt, da hat dann ja wohl das ganze ansi- kommitee geschlafen, oder wurde von den alten "C"- Leuten unterwandert (nicht böse sein, soll ein Scherz sein) Ach so, auch wenn ich leidenschaftlicher C++ Programmierer bin, C ist nicht tot, somal es ja auch ganz bewußt eine untermenge von C++ ist. und es gibt genügend Probleme, wo Klassen am Ziel vorbeigehen und strukurierte Ansätze schneller zum Ziel führen.

aber eines ist doch eigentlich wichtig, bei allem hin und her schreiben. diese methoden sind keine member der jeweiligen formulare, sondern gehören in unabhängige Funktionen oder Klassen. und ob du nun daraus klassen baust, oder ein anderer funktionen macht, ist auch viel anschauung, sollte aber in einem team gleich gehandelt werden.

schöne grüße aus berlin

volker

Hallo Volker und Alexander,

ich wüßte trotzdem nicht, was ich eine globale Funktion packen sollte.
Die angesprochenen Datumsfunktionen würde ich einer von TDateTime abgeleiteten Klasse unterbringen. Runden oder kaufmännisches Rechnen ist ein Thema für sich, getreu dem Motto "Fließkommazahlen nimmt man zum Schätzen, Ganzzahlen zum Messen".
m.E. findet sich immer eine Basisklasse, die sich um die gewünschten 'globalen' Funktionen erweitern läßt (Projektunabhängig wird's dann, wenn man eine Komponente draus macht). Ich finde das erhöht die Wartbarkeit und minimiert den Pflegeaufwand.

Aber bevor das hier zum Glaubenskrieg mutiert, schließe ich mich der Meinung an, das es jedem selbst überlassen bleiben sollte, wie er es handhabt.