Temat: CQRS czyli co....

Jarek Ż.:

i teraz: jeżeli ta dwie obiektowe wersje będą tak na prawdę "gadały" do tych samych tablic w bazie przez ORM to nie widzę tu sensu, jeżeli obie wersje (encja i agregat) będą miały swoje dedykowane tablice to ma to sens bo, zmiana ta (rozszerzenie jako poprawa wydajnosci systemu) nie wyjdzie "przed" repozytorium czyli reszta systemie nie wie o tej zmianie, system chodzi szybciej bez ingerecji w historię

A co z 3 opcją? Dwie obiektowe wersję będą "gadać" do tych samych tablic, ale nie przez ORM a "inaczej"? Wówczas repozytorium mogłoby korzystać ze różnych strategii odczytu danych z tego samego źródła.

Zmaterializowane widoki wymagają odświeżania, więc musimy mieć świadomość braku synchronizacji danych.

Temat: CQRS czyli co....

która 3.cia :)
chcę jedynie powiedzieć, że generalnie:

dwa różne widoki tych samych fizycznie danych dla mnie nie mają sensu bo wąskim gardłem jest złożoność agregatu a nie to czy uprościmy pytania do niego.

tu, w moim rozumieniu nie chodzi o "strategie odczytu", bo jak wsiądzie tysiąc ludzi na obie te strategie to nic to nie daje... dydolimy te same tablice. Jeżeli jednak złożone agregaty będą służyły tylko do operacji CRUD zaś masowe zapytania będą obsługiwane przez bardzo proste płaskie odrębne tablice to jest OK. Synchronizacja może nie być wymagana, gdy każdy zapis do repozytorium będzie implementowany jako zapis do obu tych zestawów tablic

mam wrażenie, że CQRS jest "trudne" dla osób traktujących model obiektowy jak "coś" co jest postawione na "relacyjnej bazie danych" (znormalizowanej bez redundancji) co jest głównym błędem, bo jeżeli mówiąc ORM mamy na myśli złożone mapowanie obiektowego modelu dziedziny systemu na model relacyjny z normalizacją to jest to masakra, jeżeli ORM to narzędzie wyłącznie do implementacji prostego wzorca active records lub active table, to nie ma problemu

Temat: CQRS czyli co....

Jarek Ż.:
dwa różne widoki tych samych fizycznie danych dla mnie nie mają sensu bo wąskim gardłem jest złożoność agregatu a nie to czy uprościmy pytania do niego.

Tak, złożoność agregatu jest wąskim gardłem, ale da się to obejść wyciągając skrojone DTO, używając zwięzłego zapytania. Nie wiem dlaczego uważasz rozłożenie kolejnych tabelek w bazie za tak konieczne. Z moich doświadczeń wynika, że jeden specyficzny nativeSQL jest szybszy od implementacji na pełnych agregatach, bez względu na to, czy ORM stosowany do agregatów, mieli całkowicie znormalizowany model, czy stosuje jakąś denormalizację. Skoro jest boost wydajnościowy to znaczy, że nasz query interface robi to co powinien i jeśli to wystarczy, to powinniśmy się zatrzymać. Wiadomo, że replikacja danych da jeszcze więcej wydajności, ale przedwczesna optymalizacja jest przyczyną całego zła na świecie ! :)

Temat: CQRS czyli co....

Jarek Ż.:
która 3.cia :)

Raz "Fakturę" wyciągamy przez ORMa (faktury klienta z ostatniego cyklu rozliczeniowego), a innym razem poza ORM (np. faktury z ostatniego cyklu rozliczeniowego, których kwota jest większa niż średnia kwota per klient za ostatnie N miesięcy).

W drugim przypadku można (jedna z opcji) zrealizować po stronie silnika bazodanowego. W obydwu przypadkach repozytorium zwróci klientowi kolekcję faktur.

Będą to te same obiekty domenowe, jednak widoki różne (reprezentują zbiory faktur, ale te zbiory będą mieć różne znaczenie dla użytkownika).

chcę jedynie powiedzieć, że generalnie:

dwa różne widoki tych samych fizycznie danych dla mnie nie mają sensu bo wąskim gardłem jest złożoność agregatu a nie to czy uprościmy pytania do niego.

Czy przez "złożoność agregatu" rozumiesz "złożoność grafu obiektów"? Ascii art poglądowy:

Root

 Child_1

   Child_11

      ..

   ..

   Child_1k

 ..

 Child_X

	Child_X1

	..

	Child_Xn

"Złożoność grafu obiektów" w powyższym pytaniu również nie jest precyzyjna :-) Chodzi mi o to, jak bardzo obiekty są ze sobą powiązane. Najbliższą charakterystyką takiej złożoności byłaby liczba cyklomatyczna grafu.

tu, w moim rozumieniu nie chodzi o "strategie odczytu", bo jak wsiądzie tysiąc ludzi na obie te strategie to nic to nie daje... dydolimy te same tablice. Jeżeli jednak złożone agregaty będą służyły tylko do operacji CRUD zaś masowe zapytania będą obsługiwane przez bardzo proste płaskie odrębne tablice to jest OK. Synchronizacja może nie być wymagana, gdy każdy zapis do repozytorium będzie implementowany jako zapis do obu tych zestawów tablic
mam wrażenie, że CQRS jest "trudne" dla osób traktujących model obiektowy jak "coś" co jest postawione na "relacyjnej bazie danych" (znormalizowanej bez redundancji) co jest głównym

Dla mnie trudne jest do uchwycenia czy CQRS rzeczywiście wzorcowo rozwiązuje jakiś częsty problem, czy jest jedynie alternatywą do innych rozwiązań.

Ostatnio natknąłem się na akronim SOFEA, który ogłoszony został nowym wzorcem dla aplikacji webowych, a dla mnie jawi się jako MVC, w którym do integracji poszczególnych warstw użyto różnych technologii. CQRS, ok, jest, fajnie, ale czy nie da się wyrazić za pomocą wzorców Command, Strategy ?Ten post został edytowany przez Autora dnia 25.06.13 o godzinie 15:31

Temat: CQRS czyli co....

jednak UML górą :)

mamy problem polegający że firma ma ogromną ofertę pewnych bardzo złożonych podzespołów, żeby nie psuć ich opisu i możliwości rozbudowy, model dziedziny odwzorowuje strukturę tych części. Jednak bardzo duża liczba użytkownicy sklepu internetowego regularnie przywołuje wywołuje na ekran listę podzespołów w postaci cennika, pełnego, stronicowanego, sortowanego alfabetycznie lub ceną.

Rozwiązanie: repozytorium przetrzymuje dwa komplety tych danych: jeden jako pełny katalog danych drugi jako cennik

wariant 1: całość odwołuje sie przez ORM (nie umieszczony na diagramie) do tego samego modelu danych (np. baza relacyjna)





wariant 2: pełne agregaty oraz cennik mają swoje własne niezależne dane





wariant drugi jest bez porównania lepszy, bo masowe wywołanai cennika sa szybkie i nie kolidują ze złożonymi operacjami CRUD. Klasa Repozytorium ukrywa to przed resztą świata, kóra grzecznie w to samo miejsce kieruje i zapytania o cennik i o pęłny opis produktu.

i ORM sprowadza się do mapowania activerecord, żadnych wygłupów z normalizacją.Ten post został edytowany przez Autora dnia 25.06.13 o godzinie 16:30

Temat: CQRS czyli co....

Jarek Ż.:
jednak UML górą :)

No spoko to wygląda. Dodał bym dla kontrastu opcję 0, czyli etap wyjściowy, kiedy mamy do dyspozycji tylko agregat :)

wariant drugi jest bez porównania lepszy, bo masowe wywołanai cennika sa szybkie i nie kolidują ze złożonymi operacjami CRUD.

Rzeczywiście jest najwydajniejszy, ale czy lepszy to już zależy. Wariant 1 będzie i tak szybszy od 0, a nie będzie wymagał dość złożonej infrastruktury bazy danych. Dlatego moim zdaniem najpierw należy zastosować wariant 1 i przejść w 2 jeśli 1 okaże się nadal za wolne. Poza tym szczegółem, zgadzam się w prostej linii ze wszystkim co tu zamieściłeś.

Właśnie to daje CQRS, przy poprawnej segregacji interfejsów, cały kod widoków i domeny nawet nie zauważy, że przeszliśmy z opcji 0, na 1 lub na 2. Wszystko zależy od tego jak szybkiego systemu potrzebujemy, takie jest moje ostatecznie zdanie na ten temat.

Temat: CQRS czyli co....

No spoko to wygląda. Dodał bym dla kontrastu opcję 0, czyli etap wyjściowy, kiedy mamy do dyspozycji tylko agregat :)

wystarczy "obciąć" dól ;)

wariant drugi jest bez porównania lepszy, bo masowe wywołanai cennika sa szybkie i nie kolidują ze złożonymi operacjami CRUD.

Rzeczywiście jest najwydajniejszy, ale czy lepszy to już zależy. Wariant 1 będzie i tak szybszy od 0, a nie będzie wymagał dość złożonej infrastruktury bazy danych. Dlatego moim zdaniem najpierw należy zastosować wariant 1 i przejść w 2 jeśli 1 okaże się nadal za wolne. Poza tym szczegółem, zgadzam się w prostej linii ze wszystkim co tu zamieściłeś.

ogólnie ja także stosuje zasadę, że system optymalizuję dopiero wtedy gdy wymaga optymalizacji, jednak preferuje tę metodę: zamiast grzebać w agregacie, pastwić się nad zapytaniami SQL siłując się z relacyjnością, normalizacjąc i psuć agregat upraszaczając go,

Właśnie to daje CQRS, przy poprawnej segregacji interfejsów, cały kod widoków i domeny nawet nie zauważy, że przeszliśmy z opcji 0, na 1 lub na 2. Wszystko zależy od tego jak szybkiego systemu potrzebujemy, takie jest moje ostatecznie zdanie na ten temat.

bo obiektowa zasada "otwarty na rozszerzenia i zamknięty na zmiany" ma sens...

Temat: CQRS czyli co....

... chyba rozmawiamy o dwóch różnych rzeczach.

Hm ... co "twoje" CQRS proponuje w takiej sytuacji ?
W "moim" tworzona jest (w wielkim skrócie) druga, zdenormalizowana baza danych która udostępnia dane widokom.

Szczerze "moje" CQRS zaproponuje to samo (jako końcowe i najpotężniejsze rozwiązanie), no ale żeby wyjaśnić twoje podejście całkowicie i znaleźć różnice między moim, poproszę o doprecyzowanie: przez jaki interface przejdzie zapytanie do tej zdenormalizowanej bazy i jakich obiektów użyje do realizacji zadania.

Czy to jest pytanie "podchwytliwe" ? Baza najczęściej udostępnia jeden interfejs (metodę) komunikacji - zapytania.

Hm ... jeśli zapytanie jest w requeście do serwisu to wtedy to się nazywa SQL injection, więc strzelam, że view odpytuje bezpośrednio bazę. To potencjalne ryzykowne, ale kto by się tym przejmował. Co dalej :) ?

Proszę tylko i wyłącznie o obronę twojego argumentu mówiącego, że CQRS powoduje wyciągnięcie logiki z domeny. Obchodzisz ten temat szerokim kołem, ale tak się nie da wiecznie :)

Gdzie coś takiego napisałem ? :)

No masz rację, trochę nad interpretowałem twoją wypowiedź. Dokładniej powiedziałeś o tym, że CQRS (jako segregacja interfejsów) jest złym pomysłem, bo zmusza do umieszczania logiki widoku w serwisach.

W sumie bezpośredni dostęp do bazy danych rozwiązuje ten problem ...
Nie ma serwisów, nie ma problemu ;)

Moim zdaniem twoje rozwiązanie podanego przeze mnie problemu zrobi dokładnie to samo,

Proszę o uzasadnienie :)

co więcej te twoje rozwiązanie też "domaga się" segregacji interfejsów.

Wszystko można segregować na dowolny sposób.

Temat: CQRS czyli co....

Absurd polega na tym, że to samo można uzyskać bez dodatkowej bazy, poprzez "pozwolenie" SELECTom widokowym na DIRTY_READ.

ale widok "siedzi" na "full agregatach'.... czya nie?

Niektóre siedzą (niekoniecznie koniecznie ;), a niektóre nie
Mi się podoba ta pierwsza sytuacja, ponieważ oznacza mniej pracy dla mnie, a więcej dla maszyny :)

autorstwo "tego pana" olewam bo idei sie nie chroni :)))

CQRS jest fajne, ale jego autora można olać ?

Temat: CQRS czyli co....

autorstwo "tego pana" olewam bo idei sie nie chroni :)))

CQRS jest fajne, ale jego autora można olać ?

mam tu na myśli to, że nie jest autorem a być może kimś kto to pierwszy publicznie opisał i nazwał, podobnie jak wzory matematyczne czy prawa fizyki: one nie mają autorów a co najwyżej odkrywców ;)

Po drugie co ja biedny mam zrobić, jeżeli stosowałem taki wzorzec zanim przeczytałem, że ktoś nazwał to CQRS? I zapewniam Was, że nie ja jeden.. (kurcze znowu odkrywam, że od lat pisze prozą)

P.S.
Niestety mało mnie obchodzi ile roboty ma programista, obchodzi mnie jakość finalnego produktu czyli także koszt jego utrzymania i rozwoju :)Ten post został edytowany przez Autora dnia 25.06.13 o godzinie 22:42

Temat: CQRS czyli co....

Jakub W.:

Czy to jest pytanie "podchwytliwe" ? Baza najczęściej udostępnia jeden interfejs (metodę) komunikacji - zapytania.

Hm ... jeśli zapytanie jest w requeście do serwisu to wtedy to się nazywa SQL injection, więc strzelam, że view odpytuje bezpośrednio bazę. To potencjalne ryzykowne, ale kto by się tym przejmował. Co dalej :) ?

Wiadomo, że baza udostępnia jeden interface :) bardziej mi chodziło o interfejs, który nasz system wystawia widokowi. SQLa bym nie przekazywał, bo wiąże bezpośrednio widok z bazą, a to zawsze jest złe. Ale za to cienki interfejs pomiędzy widokiem i bazą (całkowite obejście serwisów), posługujący się obiektami DTO, jest moim zdaniem idealny. To właśnie sugeruje CQRS (przynajmniej jak to tak rozumiem).

Moim zdaniem twoje rozwiązanie podanego przeze mnie problemu zrobi dokładnie to samo,

Proszę o uzasadnienie :)

No rzeczywiście, jeśli nie ma być serwisów dla widoku to i ten argument znika.

co więcej te twoje rozwiązanie też "domaga się" segregacji interfejsów.

Wszystko można segregować na dowolny sposób.

CQRS segreguje interfejsy na ciężkie, dla agregatów i lekkie dla zapytań. Jeśli robimy lekki interface dla zapytań tak jak opisałem powyżej, to jest to bardzo naturalna segregacja. Jeśli wrzucimy w jeden interface metody zwracające/zapisujące agregaty razem z metodami zwracającymi DTO, to interfejs nam spuchnie i zrobi się w nim burdel. Jego implementacja stanie się trochę takim http://en.wikipedia.org/wiki/God_object

Jeśli nie zgadzasz się z czymś co tutaj powiedziałem, czy masz lepszy pomysł to proszę o poprawkę.

Temat: CQRS czyli co....

Jakub W.:
Mi się podoba ta pierwsza sytuacja, ponieważ oznacza mniej pracy dla mnie, a więcej dla maszyny :)

i widzisz, właśnie z tego powodu staram się, by w jednym projekcie programista nie był także projektantem, bo w jego interesie jest wtedy prosta architektura a nie skuteczna ;)))

Temat: CQRS czyli co....

Czy to jest pytanie "podchwytliwe" ? Baza najczęściej udostępnia jeden interfejs (metodę) komunikacji - zapytania.

Hm ... jeśli zapytanie jest w requeście do serwisu to wtedy to się nazywa SQL injection, więc strzelam, że view odpytuje bezpośrednio bazę. To potencjalne ryzykowne, ale kto by się tym przejmował. Co dalej :) ?

Wiadomo, że baza udostępnia jeden interface :) bardziej mi chodziło o interfejs, który nasz system wystawia widokowi. SQLa bym nie przekazywał, bo wiąże bezpośrednio widok z bazą, a to zawsze jest złe. Ale za to cienki interfejs

*

pomiędzy widokiem i bazą (całkowite obejście serwisów), posługujący się obiektami DTO, jest moim zdaniem idealny. To właśnie sugeruje CQRS (przynajmniej jak to tak rozumiem).

Temat "dodatkowej" bazy danych, akurat w "tym CQRS" (bo chyba mówimy o tym samym) jest traktowany dość ignorancko. CQRS zakłada, że każda aktualizacja "dodatkowej bazy danych" powiedzie się . Oczywiście to może działać, ale na krótką metę. Na systemach które działają 24/7 i to pod dużym obciążeniem (w te celuje CQRS jak rozumiem) w pewnym momencie jakiś update się nie powiedzie (choćby z powodu starego dobrego zakleszczenia). Co CQRS proponuje robić w takiej sytuacji ? Potencjalna 'desynchronizacja' może być bardzo poważnym problemem.

Wracając do serwisów: w tym przypadku CQRS robi takie małe założenie, że w SQL można wygenerować dane, których potrzebuje View. W ogólnym przypadku (dowolny widok + SQL bez rozszerzeń) nie da się tego zrobić. SQL (bez rozszerzeń) nie jest 'normalnym' językiem programowania.

Tworzenie odrębnej, zdenormalizowanej i potencjalnie zdesynchronizowanej bazy danych w której znajdują się (potencjalnie) procedury generujące dane dla view(!), w celu ograniczenia transferu danych z serwisu do klienta chyba nie jest dobrym pomysłem.

Nie wiem jak inni, ale ja spróbowałbym raczej np. kompresji danych wymienianych pomiędzy klientem i serwerem ...

Architektura nie powstaje po to, "żeby system działał szybko"; od tego są algorytmy i hardware.
Architektura jest po to, żeby programista mógł szybko stworzyć łatwy w analizie i odporny na bugi kod.

co więcej te twoje rozwiązanie też "domaga się" segregacji interfejsów.

Wszystko można segregować na dowolny sposób.

CQRS segreguje interfejsy na ciężkie, dla agregatów

*
ciężkie i jednocześnie cienkie ? ;)

i lekkie dla zapytań.

Co to jest ciężki / lekki interface ?

Jeśli robimy lekki interface dla zapytań tak jak opisałem powyżej, to jest to bardzo naturalna segregacja.

IT nie jest ani specjalnie ciężkie, ani lekkie, ani naturalne.
Dlaczego w ogóle używasz takich pojęć w odniesieniu do technologii ?

To może jeszcze napiszesz, że VB is totaly gay!!! ;)

Jeśli wrzucimy w jeden interface metody zwracające/zapisujące agregaty razem z metodami zwracającymi DTO, to interfejs nam spuchnie i zrobi się w nim burdel. Jego implementacja stanie się trochę takim http://en.wikipedia.org/wiki/God_object

Twórca tego pojęcia albo myli klasę z obiektem, albo klasę z demonem...

Jeśli nie zgadzasz się z czymś co tutaj powiedziałem, czy masz lepszy pomysł to proszę o poprawkę.

W sumie mam - programy 'biznesowe' powinny koncentrować się na funkcjonalności, a nie wydajności.
Wydajnością powinni się zająć ludzie, dla których 'wydajność' jest celem 'biznesowym'.

Temat: CQRS czyli co....

Jarek Ż.:

Jakub W.:
Mi się podoba ta pierwsza sytuacja, ponieważ oznacza mniej pracy dla mnie, a więcej dla maszyny :)

i widzisz, właśnie z tego powodu staram się, by w jednym projekcie programista nie był także projektantem,

Całkowicie się z tym zgadzam. Podział ról zdecydowanie ułatwia pracę.

bo w jego interesie jest wtedy prosta architektura a nie skuteczna ;)))

Prosta znaczy skuteczna. I na odwrót.

Temat: CQRS czyli co....

Jakub W.:
Temat "dodatkowej" bazy danych, akurat w "tym CQRS" (bo chyba mówimy o tym samym) jest traktowany dość ignorancko. CQRS zakłada, że każda aktualizacja "dodatkowej bazy danych" powiedzie się . Oczywiście to może działać, ale na krótką metę. Na systemach które działają 24/7 i to pod dużym obciążeniem (w te celuje CQRS jak rozumiem) w pewnym momencie jakiś update się nie powiedzie (choćby z powodu starego dobrego zakleszczenia). Co CQRS proponuje robić w takiej sytuacji ? Potencjalna 'desynchronizacja' może być bardzo poważnym problemem.

nie traktuj "drugiej bazy" jako coś za co warto umierać, to tylko kopia taka sama jak hurtowni danych w systemach BI

Tworzenie odrębnej, zdenormalizowanej i potencjalnie zdesynchronizowanej bazy danych w której znajdują się (potencjalnie) procedury generujące dane dla view(!), w celu ograniczenia transferu danych z serwisu do klienta chyba nie jest dobrym pomysłem.

czyżby? a zejście za czasu oczekiwania z kilkudziesięciu sekund do poniżej sekundy ma sens?

Temat: CQRS czyli co....

Jakub W.:

Jarek Ż.:

Jakub W.:
Mi się podoba ta pierwsza sytuacja, ponieważ oznacza mniej pracy dla mnie, a więcej dla maszyny :)

i widzisz, właśnie z tego powodu staram się, by w jednym projekcie programista nie był także projektantem,

Całkowicie się z tym zgadzam. Podział ról zdecydowanie ułatwia pracę.

bo w jego interesie jest wtedy prosta architektura a nie skuteczna ;)))

Prosta znaczy skuteczna. I na odwrót.

wielu programistów uważa prosta = "mało kodu"... a tego nie lubię ;)

Temat: CQRS czyli co....

Z początku nie rozumiałem kwestii "logiki biznesowej w widoku", ale muszę przyznać, że taka sytuacja może wystąpić. Tutaj muszę przyznać rację Jakubowi, który początkowo wyciągnął taki argument.

Wyobraźcie sobie obiekt Wniosek. Obiekt ten ma złożony cykl życia, przechodzi przez wiele statusów od utworzenia, przez zatwierdzenia, realizację i zakończenie.
Do pewnego momentu wniosek można edytować. Możliwość edycji zależy od tego, w jakim jest statusie, ale też do wyobrażenia jest sytuacja, w której więcej rzeczy może wchodzić w grę. To jest logika agregatu i z pewnością najlepsze miejsce to metoda na agregacie czyMoznaEdytowac().
No i teraz mamy zrobić raport, który wyświetla wszystkie wnioski i zaznacza na zielono, te które są jeszcze edytowalne.
Jeśli nasza implementacja interface query (zgodnie z założeniami CQRS) zwraca gotowe DTO dla widoku, to też musi mieć możliwość analizy, czy edycja jest dozwolona. W obliczy takiego problemu możemy:
- wyciągać wszystkie agregaty wniosku i pytać się każdego po kolei, czy jest edytowalny (wydajność padnie)
- wyciągać tylko potrzebne pola do stworzenia raportu i zdublować logikę odpowiadającą za rozstrzyganie, czy wniosek jest edytowalny (rozwiązanie karygodne)

Jak wiać implementacja query interface może mieć potrzebę sięgnięcia do logiki biznesowej. W takim przypadku, chyba jedynym wydajnym i sensownym rozwiązaniem jest tworzenie oddzielnej tabeli, specjalnie dla tego raportu. Do tej tabeli dane by były zapisywane, przy okazji zapisu każdej zmiany agregatu.

Temat: CQRS czyli co....

Marcin M.:
Jak wiać implementacja query interface może mieć potrzebę sięgnięcia do logiki biznesowej. W takim przypadku, chyba jedynym wydajnym i sensownym rozwiązaniem jest tworzenie oddzielnej tabeli, specjalnie dla tego raportu. Do tej tabeli dane by były zapisywane, przy okazji zapisu każdej zmiany agregatu.

jeżeli często używam informacji o możliwości etycji to DTO niech go ma... nie musi go zawsze widok wyświetlać

Temat: CQRS czyli co....

Mi się podoba ta pierwsza sytuacja, ponieważ oznacza mniej pracy dla mnie, a więcej dla maszyny :)

i widzisz, właśnie z tego powodu staram się, by w jednym projekcie programista nie był także projektantem,

Całkowicie się z tym zgadzam. Podział ról zdecydowanie ułatwia pracę.

bo w jego interesie jest wtedy prosta architektura a nie skuteczna ;)))

Prosta znaczy skuteczna. I na odwrót.

wielu programistów uważa prosta = "mało kodu"... a tego nie lubię ;)

Ym ? Dlaczego ? :)

Temat: CQRS czyli co....

Jakub W.:

wielu programistów uważa prosta = "mało kodu"... a tego nie lubię ;)

Ym ? Dlaczego ? :)

bo można przegiąć zbyt upraszczając... można uniknąć dziesiątek deklaracji klas, waląc wszystkie operacje do jednej... itp. itd..