On 21/01/2024 17:19, Przemek Biernat wrote:
> 1. Pojedyncza odpowiedzialność. Według mnie klasy wymyślono po to aby grupować i zamykać funkcjonalność. Czy chodzi o to aby klasy miały po jednej metodzie?
Klasa o jednej metodzie jest praktycznie bezużyteczna.
Wiec na pewno nikt nie wpadłby na tak głupi pomysł.
Są rózne koncpecje co to jest klasa, od podobnych do Java bean po good
object. Wszystkei znajdziesz w żywym kodzie i znajdziesz też wielu
zwolenników pisania na oba sposoby. Obserwacja: i tak będziesz pisał
tak, jak kod zastany.
> 2. Otwarte zamknięte. Przykład: wzorzec fabryka, jak ci dochodzi kolejna klasa to i tak musisz zmienić kod fabryki i dodać generowanie klasy.
Nikoniecznie, może istnieć inna fabryka produkująca inne typy, o typie
bazowym takim samym jak ta pierwsza. Innymi słowy *niektóre* fabryki nic
nie muszą wiedzieć o nowych implementacjach zwarcanej przez nie abstrakcji.
Ba, zaryzykuję stwierdzenie, że w prawidłowo skonstruowanej abstrakcji,
taki rodzaj multi-fabryk jest często spotykanym wzorcem. Implementacja
produkuje klasy o okreslonym interfejsie z puli tych, które zna jako
swoją implementację. Nie musi nic wiedzieć o innej implementacji tego
samego interfejsu.
> 3. Liskov. To już jest czysty idealizm. Często nie udaje się aby wszystkie klasy potomne implementowały funkcje wszystkie funkcje klasy bazowej. Wyjściem są wiszące metody lub rzutowanie, osobiście preferuje static_cast z kontrolą typu.
Jesli potomne klasy mają "wiszące" metody to coś spieprzyłeś. Bardzo
łatwo jest to spieprzyć czytając wszelkie poradniki z okolic "class Ryba
: publi Zwierze". To zazwyczaj stek bzdur pisany przez ignorantów. Pełno
tego w ksiażkach, autorzy najwyraźniej nigdy nie wyszli poza ten poziom
komplikacji.
Zainteresuj się rozwiązaniem tego problem, na przykład za pomocą
doprecyzowania interfejsu wizytacją, czy jakąkolwiek inną metodą tego typu.
> A co powiecie gdyby iteratory były przekażywane przez wskaźnik i taki iterator był zwracany na zewnątrz klasy w celu wykonania algorytmu poza klasą ale na kontenerze klasy.
Powiedziałbym, że to normalna praktyka od początku istnienia koncepcji
iteratorów. Przykładowo, całkiem naturalne jest zwracanie iteratora
java-like własnie przez [smart]pointer. Nie ma w tym nic dziwnego. Robię
tak od dziesięcioleci.
Iteratory STL maja inną koncepcję działania, są kopiowalne.
Używasz obu konstrukcji, głównie dlatego, że Java-like łatwiej jest
zrobić abstrakcyjny, a stl lepiej się optymalizuje.