3. Verwaltung von vielen Header-Dateien

Verwaltung von vielen Header-Dateien

  • J

    Vielleicht hab ich mich ja auch nicht richtig ausgedrückt. Den ich verstehs immer noch nicht.
    Also angenommen ich habe hier eine Klasse "Window". Diese besitzt als ein Element einen Pointer auf die Klasse "Button" (also Anker zu einer Liste von Buttons). Die Klasse "Button" wiederum besitzt aber auch als ein Element ein Pointer auf die Klasse "Window" (er soll wissen auf welchem Fenster er liegt).
    Beide Klassen sind in unterschiedlichen Dateien definiert ( window.h und button.h ).

    Wie müsste ich diese jetzt includen?

    0
  • ?
     

    // HEADER
class Button
{
private:
class Window *win;
// ...
};
// <-- CPP -->
#include "Window.h"

    // HEADER
class Window
{
private:
class Button *btn;
}

// <-- CPP -->
#include "Button.h"

    Diese Gegenseitige Abhängigkeit ist aber extrem schlecht 👎

    0
  • J

    @Blabbbbb: Danke, so funktioniert es. Aber warum ist sowas extrem schlecht? Und welche Alternativen hab ich den?

    0
  • D

    JDieskau schrieb:

    @Blabbbbb: Danke, so funktioniert es. Aber warum ist sowas extrem schlecht? Und welche Alternativen hab ich den?

    Design Problem. Window muss über Buttons bescheid wissen und muss die verwalten. Klar.
    Aber wozu muss ein Button wissen, was Window ist oder gar einen Zeiger darauf halten?! Grob gesagt. Wenn du einen Button hast, könnte der doch auch ohne ein Window drum herum existieren. Jedoch ein Window, dass Buttons hat, muss die selber verwalten, oder was damit machen.

    Alternative. Design überdenken. 😉

    0
  • J

    So mit dem "designen" hab ich es noch nicht so wirklich. Wie gesagt, Anfänger...
    Zum Beispiel die Position von einem Button ist als x,y-Koordinate gespeichert, aber nicht die Bildschirmkoordinaten, sondern 0,0 wäre dann oben links vom entsprechendem Fenster auf dem der Button liegt. Somit wenn der Button "sich zeichnen soll" muss er aber doch wissen wo er auf den Bildschirmkoordinaten liegt. Und dazu braucht er die Angaben von dem Fenster auf dem es liegt.

    Eine bessere Lösung würde mir da jetzt nicht einfallen. Wie würde man das sonst machen? Der Klasse "Window" das zeichnen der Buttons überlassen? So richtig blick ich das mit dem designen von Projekten wirklich noch nicht. Gibt es für so was vielleicht gute Anleitungen? Also wie man Projekte richtig plant bevor man losschreibt? Oder Buchempfehlungen?

    0
  • ?

    Somit wenn der Button "sich zeichnen soll" muss er aber doch wissen wo er auf den Bildschirmkoordinaten liegt.

    Jo, muss er wohl, aber er sollte sich das nicht (irgendwie) selbst holen, sondern bei dem Funktionsaufruf "zeichnen" das einfach als parameter übergeben bekommen, bzw schon im konstruktor.
    Falls du die werte noch weiterhin brauchst kannst du es einfach intern speichern, aber eben nur diese 2 werte.

    0
  • J

    Es sind einige mehr Variablen die ich da übergeben müsste und auch einiges andere was ich so umschreiben muss. Was genau ist den an dieser gegenseitigen Abhängigkeit so fatal? Was kann mir da im schlimmsten Fall passieren? Welche Auswirkungen hat das? Was würde es ändern wenn die Button-Klasse sich das nicht holt, sondern alles per Werte übergeben bekommt (außer das es meiner Meinung nach unübersichtlicher werden würde)...

    0
  • D

    JDieskau schrieb:

    Es sind einige mehr Variablen die ich da übergeben müsste und auch einiges andere was ich so umschreiben muss. Was genau ist den an dieser gegenseitigen Abhängigkeit so fatal? Was kann mir da im schlimmsten Fall passieren? Welche Auswirkungen hat das? Was würde es ändern wenn die Button-Klasse sich das nicht holt, sondern alles per Werte übergeben bekommt (außer das es meiner Meinung nach unübersichtlicher werden würde)...

    Hmm. So Generell würde ich sagen, dass dir diese Abhängigkeiten bei einem grösseren Projekt ziemlich schnell das Leben schwer machen. Per Übergabe ist auf eine gewisse Art schöner, da dir dann bewusst ist, dass du da Daten übergibst. Wenn ein Button jetzt auf ein Window zugreifen kann, dann kann der doch auch Funktionen davon aufrufen und das ist nicht "logisch". Warum sollt ein Button das Recht haben sein Window, wo er drin liegt zu bewegen oder zu resizen?!

    Ich würde mal sagen, dass design immer wichtiger wird, je grösser das Projekt ist/wird. Aber du kannst es ruhig mal so machen. Früher oder später wirst du merken, was ich meine. 😉

    0
  • ?

    Wenn du mehrere Daten übergeben musst, kannst auch einfach folgendes machen:

    struct meineButtonDaten {
int positionX;
int positionY;
std::string name;
....
}
//in button
void button::Zeichnen(const &meineButtonDaten daten)
{
...
}

    So gegenseitige Abhängigkeiten führen zu einem sehr starren code - spätere Änderungen sind teilweise gar nicht mehr möglich, man kann eigentlich alles gleich neu schreiben. Solche Änderungen passieren wohl sicher öfter, spätestens beim dritten mal würdest du auch von alleine draufkommen das solche Abhängigkeiten keine gute idee sind 🙂

    0
  • J

    Gut, die Daten per struct zusammen zufassen würde es dann wieder schön übersichtlich machen. So gefällt mir das. Mir ist so wieso gerade aufgefallen das es gar nicht mal soo gut ist, einen Pointer in der Buttonklasse zu haben, dieser ist ja dann in jedem Button enthalten. Eigentlich würde es bei einer Liste ja einmal reichen.

    Und das Argument mit dem starren Code akzeptiere ich jetzt mal 🙄 Hab ja noch nicht so viel Erfahrung. Und irgendwann mal in diese "Falle" rein zulaufen möcht ich nun auch nicht... so kann ich den Code dafür auch gleich mal richtig umschreiben. Am besten gleich mit Vererbung, dann kann ich mir das auch mal richtig genauer zu gemüte ziehen (ich meiner jetzt nicht Button soll von Window geerbt werden, sondern eher so mehrere Schaltflächen)

    Danke also erstmal für eure Hilfe!

    0
Anmelden zum Antworten