Najlepsza metoda dostępu do pól klasy "nadrzędnej" - czyli elegancja Francja

Hey, wszystkim. Mam banalny problem. Ćwiczę C++, czytam Symfonię ale nie znalazłem odpowiedzi na jedno nurtujące mnie pytanie.

Jeżeli klasa B dziedziczy po A, to mamy dostęp z klasy B do pól klasy A i nie ma problemu. Pan Grębosz natomiast napisał że dziedziczenia używamy, jeżeli chcemy jakąś klasę rozszerzyć (jakby ukonkretniamy jej dzieci - Samochód->Osobowy->Volvo). Natomiast gdy mamy taką sytuację jak ja, to umieszczamy wskaźnik do obiektu jako pole klasy. A więc aby wyjaśnić dokładnie o co mi chodzi. Mam taką sytuację

class A{
    int pole;
    B*b;
}

class B : public C {
  
}

Klasa A to jest jakby okno główne programu, natomiast B to jakiś element tego okna, np. element interfejsu, ramka w oknie, cokolwiek. Niestety jest tak że potrzebuję móc z klasy B odwołać się do pola "pole" klasy A aby wartości z tego pola użyć. Najprostszym rozwiązaniem jest przekazanie wskaźnika klasy A do klasy B (np. w konstruktorze albo jakąś metodą). Wydaje mi się jednak to mało "eleganckie" i przy kilkunastu takich klasach będzie to raczej mało efektywne. Dodam jeszcze że klasa B dziedziczy po jeszcze innej klasie, więc dziedziczenie po A odpada. Jak najlepiej rozwiązać ten problem? Pozdrawiam

1. Jak najbardziej potrzebna ci tu delegacja i absolutnie nie dziedziczenie.
2. Jeśli obiekt B potrzebuje tej wartości to mu ją przekaż w konstruktorze. Czy on potrzebuje jakiejś referencji do tej wartości? Wtedy to "pole" mozesz zamknąć w jakiejś nowej osobnej klasie i mieć wskaźnik do niego zarówno w A jak i w B. Ma to sens, bo skoro ta zmienna jest taka ważna to znaczy że ma ona jakiś sens dziedzinowy.

Dzięki za odpowiedź. Jak najbardziej mógłbym zrobić tak jak piszesz w punkcje 2. ale ja już wiem że tych zmiennych pewnie byłoby dużo więcej (pewnie i jakieś metody się trafią) i tworzenie osobnej klasy będącej swoistym pojemnikiem na różne zmienne chyba nie jest dobrym pomysłem. A z tym punktem 1, to chodzi Ci o takie delegacje jak np. w C#? Czy zrobienie tego "na chama" przekazując wskaźnik do obiektu A w np. konstruktorze B będzie bardzo złe?

Cykliczne referencje raczej nic dobrego nie wróżą bo oznaczają zwykle że masz złamaną zasadę jednej odpowiedzialności i masz jakąś klasę która robi zbyt wiele rzeczy na raz. Może to znaczy ze klasa A lub B powinny być podzielone na mniejsze kawałki.

Uszczególnię więc: ta klasa, to klasa głównego okna a te pola to pola odpowiadające za szerokość i wyokość okna. Wiem że poiwnienem zrobić jakąś osobną klasę do ustawień tak jak napisałeś ale chciałem ten problem uogólnić bo przecież nie tylko ustawienia będę potrzebował w klasie B. Myślałem o klasie statycznej dla ustawień bo przecież nie potrzebuję tworzyć egzemplarza klasy config (i tak bym musiał przekazywać ten wskaźnik) a tak będę mógł napisać po prostu Config::WindowWidth; i pobierze mi szerokość. W JAVIe jest mechanizm dzięki, któremu mogę deklarować zmienne statyczne w klasie. W C++ ten mechanizm również istnieje ale dopiero od wersji 11 (we wcześniejszych tylko z const static, ale przez const nie mogę zmieniać tych pól) i przy zastosowaniu go kompilator rzuca warningi, że może mi to w starszych kompilatorach nie przejść. Czy warto to w ten sposób JAVowski zrobić, tj. stworzyć klasę z polami statycznymi dla Configu?

Chwila! Przecież jeżeli utworzę obiekt np. configu w którym będzie zmienna statyczna to w każdym obiekcie tej klasy będzie ona i tak wspólna dla nich! Ale pytanie pozostaje, czy to dobry pomysł?

1. Zaręczam ci że pola statyczne C++ miał jeszcze zanim się urodziłeś.
2. Nie jest to jakieś mega eleganckie ale może ujdzie. Możesz też pomyśleć o singletonie albo w ogóle o użyciu jakiegoś IoC w tym programie. Pewnie ułatwiłoby ci to życie ;)

Zrobiłem sobie klasę dziedziczącą po QSettings (używam Qt) i tam w konstruktorze definiuję sobie ustawienia:

Settings::Settings()
{
   this->setValue("ustawienie", "wartosc");
}

Jak rozumiem jeśli zmienię te dane to "zmienią się/zaaktualizują" w każdym obiekcie Settings. Przejdzie takie rozwiązanie?