Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > pl.comp.programming > #32438 > unrolled thread

Jak zrobić to elegancko i obiektowo?

Back to article view | Back to pl.comp.programming

Contents

  Jak zrobić to elegancko i obiektowo? Borneq <borneq@antyspam.hidden.pl> - 2019-02-17 14:13 +0100
    Re: Jak zrobić to elegancko i obiektowo? szykcech@gmail.com - 2019-02-17 06:07 -0800

#32438 — Jak zrobić to elegancko i obiektowo?

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ć?

[toc] | [next] | [standalone]

#32439

> 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.

[toc] | [prev] | [standalone]

Back to top | Article view | pl.comp.programming

csiph-web