Z obiektowego punktu widzenia uchodzi za złą praktykę operowanie na
polach obiektu za pomocą obiektu innej klasy, nie mówiąc o tym że w
takim razie te pola powinny być publiczne.
Ale jak w takim razie zrobić elegancko taką rzecz: problem, który
powstał przy wciąganiu danych z raportu WhereIsIt do mojego programu do
katalogowania dysków:
Mam klasę MemEntry, w której są takie dane jak filename, size, time i
ogólnie dane w rodzaju fileinfo. Mam klasę MemChunk, która zawiera listę
MemEntry dla jednego katalogu.
Z drugiej strony raport czytam za pomocą klasy Reader. Zna ona format
raportu. Czyta ,,chunk" czyli porcje dotyczące jednego katalogu do listy
stringlist w której mamy pola - kolumny. Teraz dla wierszy chunka
wołany jest konstruktor MemChunk , który dla każdego wiersza woła
konstruktor MemEntry. To MemEntry wypełnia swoje pola w konstruktorze,
biorą np. filename kolumn 0 + 1 (filename+ext), size parsuje z kolumny
4-tej a czas z 5-tej. (numery kolumn nie są na stałe a wynikają z
nagłówka raportu). I wszystko było by dobrze, ale MemEntry i MemChunk
miały nie wiedzieć o formacie raportu! To może tworzyć pusty MemEntry i
wypełniać przez klasę Raport? Też źle z obiektowego punktu widzenia. Jak
to elegancko rozwiązać, może jakieś klasy pośredniczące?

W innym miejscu tego projektu z kolei jest bazowa klasa drzewka, która
ma takie metody jak addChild, listę childów tego typu. Z tego dziedziczy
klasa mająca dodatkowe pola i metody, niestety, jak w tych metodach
odwołujemy się do childów, to musi być dynamic_cast, jak to można
przeprojektować?

do góry

> I wszystko było by dobrze, ale MemEntry i MemChunk
> miały nie wiedzieć o formacie raportu! To może tworzyć pusty MemEntry i
> wypełniać przez klasę Raport? Też źle z obiektowego punktu widzenia. Jak
> to elegancko rozwiązać, może jakieś klasy pośredniczące?

Bronek! Znowu nie odrobiłeś pracy domowej! Wzorzec wizytator jest twoim
rozwiązeniem...

> W innym miejscu tego projektu z kolei jest bazowa klasa drzewka, która
> ma takie metody jak addChild, listę childów tego typu. Z tego dziedziczy
> klasa mająca dodatkowe pola i metody, niestety, jak w tych metodach
> odwołujemy się do childów, to musi być dynamic_cast, jak to można
> przeprojektować?

dynamic_cast nie jest niczym złym. Inna droga to koszmary szablonów (drzewko jako
szablon parametryzowany klasą liścia) - jednak na oczy nie widziałem takiego drzewka.

do góry