Herzlich Willkommen, lieber Gast!
  Sie befinden sich hier:

  Forum » C / C++ (ANSI-Standard) » Bemühungen um einen "sauberen" Programmierstil

Forum | Hilfe | Team | Links | Impressum | > Suche < | Mitglieder | Registrieren | Einloggen
  Quicklinks: MSDN-Online || STL || clib Reference Grundlagen || Literatur || E-Books || Zubehör || > F.A.Q. < || Downloads   

Autor Thread - Seiten: > 1 <
000
31.07.2008, 08:31 Uhr
katoon



Bei Konsolenprogramen hatte ich früher immer einen "geregelten" Ablauf. Das Programm fing an und arbeitet sich immer nach unten durch. Funktionen erhielten Ihre Parameter die wiederum den gewünschten Rückgabewert lieferten. In meinen Augen ein sehr wichtiger Aspekt, da ich Funktionen, die eine Funktion, erfüllten immer wieder verwenden konnte und wusste, was ich übergeben muss damit was bestimmtes zurückgeliefert wird. Zudem machte sowas den Code lesbarer und auch besser zum debuggen.
Nun bin ich mitlerweile bei grafischen Oberflächen angelangt und irgendwie geht das Konzept dort nicht mehr auf.
Funktionen beinhalten Parameter die wiederum andere Funktionen benötigen, diese aber nicht direkt aufrufen. Bestes Beispiel ist der versuche eines "Option" Dialogs. Wird dieser mit OK bestätigt werden die Daten im Programm gespeichert. Es wird aber keine Funktion danach aufgerufen, die mit diesen Daten weiterarbeitet. Ganz im Gegenteil die Funktion die die Einstellungen aus dem "Option" Dialog benötigt wird an anderer Stelle aufgerufen kann aber Ihrerseits nicht wieder den "Option" Dialog aufrufen, das würde ja keinen Sinn machen jedes mal wieder den "Option" Dialog aufzurufen.
So lange Rede kurzer Sinn:
Gibt es dazu eine elegantere Lösung als solche Sachen in globalen Variablen im Programm zu speichern damit jede Funktion darauf zugreifen kann. Denn irgendwie kann ich mich nicht damit anfreunden nach den #include Anweisungen oder in der Header Datei ein lange Liste von Variablen Deklarationen zu haben.

Vielen Dank
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
001
31.07.2008, 11:10 Uhr
Bruder Leif
dances with systems
(Operator)


Moin!

Bastle Dir eine Singleton-Klasse, die die Daten haelt. Einmal (global) instantiieren und darueber auf die Optionen zugreifen. Dabei kann auch gleich noch das Laden und Speichern (die "Persistenz") der eingestellten Optionen mit eingebaut werden, oder Ueberpruefungen, ob sich zwei Optionen nicht miteinander vertragen etc.
--
Mit 40 Fieber sitzt man nicht mehr vor dem PC.
Man liegt im Bett.
Mit dem Notebook.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
002
04.08.2008, 15:19 Uhr
stephanw
localhorst


Oder so:

Baue eine Klasse Options, welche die auswählbaren Optionen in geeigneter Weise enthält (Strings, Zahlen, was auch immer). Der Dialog (bzw. die Funktion, die durch das "OK" aufgerufen wird), trägt diese Dinge in ein solches Options-Objekt ein. Der Code, der diese Optionen später auswertet, muss sie aus genau diesem Options-Objekt lesen.

Damit das klappt, musst Du natürlich dieses Options-Objekt natürlich einmal anlegen und den beiden Instanzen bekanntmachen, die damit arbeiten sollen. So etwas passiert typischerweise in einer Art Factory, die die Applikation zusammenbaut - also die GUI erstellt, fachliche Komponenten anlegt usw. . Dort erfolgt die Verdrahtung.


C++:
Options options = new Options;
Algorithm* myAlgorithm = new Algorithm(options);
Dialog* myDialog = new Dialog(options);
...



Mit Singletons bin ich immer etwas vorsichtig. Letztlich sind das globale Variablen, die schon bei einem Projekt mittlerer Größe zum Problem entwickeln können, weil sich irgendwann alles gegenseitig beeinflusst.
--
Reden ist Schweigen und Silber ist Gold.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
003
31.08.2008, 12:34 Uhr
berniebutt



Konsolenprogramme sind "prozedural" organisiert, "GUI"-Programme dagegen "nachrichten-orientiert". Es hilft nichts, Du musst einfach lernen, an einigen Stellen umzudenken! Globale Daten sowie Funktionen mit Parameterlisten kannst Du übrigens weiter verwenden. Nur eben nicht für die GUI-Oberfläche, in der der Anwender beliebig herumturnt.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
004
31.08.2008, 23:51 Uhr
0xdeadbeef
Gott
(Operator)


Ich halte eine Singleton-Klasse hier für keine sinnvolle Idee. Ich halte Singleton-Klassen in aller Regel sowieso für keine sinnvolle Idee (sie sind im Grunde nichts anderes als globale Variablen mit dicker Schminke), aber in diesem Fall ist es völlig unnötig und macht den Code weniger flexibel.

Es geht hier doch um einfache Objektorientierung - die Optionen sollten da verwaltet werden, wo sie logisch hingehören. Fenstereinstellungen in ihr jeweiliges Fenster, Loggingeinstellungen zum jeweiligen Logger, und so weiter. Oder monolithisch in einer Optionen-Klasse, und dann den Objekten, die Zugriff darauf brauchen, eine Referenz andrehen. Für die Eventverarbeitung muss sich halt das Objekt, das das Ereignis erhält, den entsprechenden Kontext vorhalten. (Oder, eigentlich schöner, der Eventhandler - so macht das z.B. gtkmm)
--
Einfachheit ist Voraussetzung für Zuverlässigkeit.
-- Edsger Wybe Dijkstra
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
Seiten: > 1 <     [ C / C++ (ANSI-Standard) ]  


ThWBoard 2.73 FloSoft-Edition
© by Paul Baecher & Felix Gonschorek (www.thwboard.de)

Anpassungen des Forums
© by Flo-Soft (www.flo-soft.de)

Sie sind Besucher: