🚀 go-pugleaf

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.