Temat: model, helper czy klasa?

Łukasz K.:

Wojciech Soczyński:

Łukasz K.:
Jakub vs Jarek. Dotnet vs Java :D Obaj macie rację biorąc pod uwagę nawyki z Waszych środowisk ;) Tak słyszałem ;)

Miałbyś 100% racji, gdyby Jarek był programistą :>

Ufam, że nie projektuje w próżni ;)

prawie, robię projekty PIM :)

Temat: model, helper czy klasa?

Jaką przewagę daje przeniesienie kodu z kontrolki do ModelView ?

masz np. klasę dziedzinową Samochód, zapytana o "Dane samochodu" przez "wypasiony" interfejs poda komplet danych ze zdjęciem, zapytana przez "ubogi" dobierze minimum podstawowych danych.

Niekonieczne. Do widoku (kontrolki) można przekazać obiekt (o ustalonym interface) który dopiero w momencie odwołania do konkretnej metody / property będzie pobierać dane. Tzn. można wykorzystać mechanizm lazy loading.

W takim przypadku zostaną pobrane tylko wymagane dane.

Tak wiec model faktyczny można przykryć takim adapterem. Pożytek jest taki, że po napisaniu interfejsu na Androida interfejs jest nadal prosty i lekki, a odwołania z Androida przechwytuje adapter Vidoku,

Na pewno to jest zaletą. Ma ją również HTML z tym, że nie trzeba go portować.

Nie wiem, może ModelView komuś przypadł do gustu, ale wg. mnie ten pattern wg. mnie ma dwie poważne wady:

1 (mniej poważna ;). Łączy formatowanie / preparowanie danych i obsługę 'gestów' użytkownika czego efektem jest bałagan w kodzie.

2 (poważna). Ciężko stworzyć hierarchię między klasami ModelView a to oznacza, że kod w nich będzie redundantny (np. te same przekształcenia w róznych klasach MV) tzn. będzie go dużo, będzie narażony na błędy i ciężko będzie go zmieniać (jedna zmiana w modelu potencjalnie może się przenieść na wiele zmian w wielu klasach MV). To wiem z autopsji. :)

chodzi o to, że "Model jest święty", modeluje w 100% logikę i nie naginam go z żadnego powodu, tylko dzięki temu model jest "wymiennny i przenoszalny".

Nigdzie nie sugerowałem, żeby zmieniać model w związku z formą View. :)

W kwestii helpera nie wiem co to jest,

To jest kod proceduralny w klasie :) podobnie jest z klasami ModelView z resztą.

ale jaką ma odpowiedzialność, jaką wartość dodaną wnosi?

W idealnej sytuacji helper to coś takiego: http://c2.com/cgi/wiki?HelperPattern
Niestety najczęściej jest to 'kod proceduralny w klasie' który jest efektem złej architektury.

Temat: model, helper czy klasa?

masz np. klasę dziedzinową Samochód, zapytana o "Dane samochodu" przez "wypasiony" interfejs poda komplet danych ze zdjęciem, zapytana przez "ubogi" dobierze minimum podstawowych danych.

Niekonieczne. Do widoku (kontrolki) można przekazać obiekt (o ustalonym interface) który dopiero w momencie odwołania do konkretnej metody / property będzie pobierać dane. Tzn. można wykorzystać mechanizm lazy loading.

"lazy loading" to chyba raczej pociąganie z bazy... (repozytorium...)???? a vidoc nie ma kontaktu z utrwalaniem...

Tak wiec model faktyczny można przykryć takim adapterem. Pożytek jest taki, że po napisaniu interfejsu na Androida interfejs jest nadal prosty i lekki, a odwołania z Androida przechwytuje adapter Vidoku,

Na pewno to jest zaletą. Ma ją również HTML z tym, że nie trzeba go portować.

w sumie kod html "pyta" tego kogo mu wskażą, ale to faktycznie "typowy" vidoc

Nie wiem, może ModelView komuś przypadł do gustu, ale wg. mnie ten pattern wg. mnie ma dwie poważne wady:

1 (mniej poważna ;). Łączy formatowanie / preparowanie danych i obsługę 'gestów' użytkownika czego efektem jest bałagan w kodzie.

ja ten wzorzec odbieram jako zmodyfikowany dedykowany interfejs, pewna fasadę...

2 (poważna). Ciężko stworzyć hierarchię między klasami ModelView

???

jak wyżej...

Temat: model, helper czy klasa?

W idealnej sytuacji helper to coś takiego: http://c2.com/cgi/wiki?HelperPattern
Niestety najczęściej jest to 'kod proceduralny w klasie' który jest efektem złej architektury.

nie kupuje tego :), wolę "projektowanie poprzez odpowiedzialność", taki kod "do czegoś służy"....

Temat: model, helper czy klasa?

Marcin Drwięga:
...
Nie wiem szczerze czy to dobrze rozumuję. Tak czy siak, z helperów korzystam również po to by uniknąć stosowania Singletonów.

Singleton jest takim samym pełnowartościowym wzorcem jak i 30 kilka pozostałych. Jest pożyteczny w niektórych zastosowaniach. No chyba że masz na myśli Boski Obiekt... Ale to nie jest Singleton.

Temat: model, helper czy klasa?

Olek, Boski Obiekt z zasady jest Singletonem :)))

Temat: model, helper czy klasa?

Jarek Żeliński:
...
nie kupuje tego :), wolę "projektowanie poprzez odpowiedzialność", taki kod "do czegoś służy"....

Zgadzam się z Tobą Jarku, że projektowanie poprzez odpowiedzialność jest najlepszym punktem wyjścia, jednakże...

Każda klasa powinna mieć swoją zasadność istnienia i pełnić jakąś rolę w SI, to prawda. Często jednak idziemy na pewne kompromisy: świat nie jest idealny, doba ma tylko 24 godziny a entropia ma tendencje do zwiększania się :)

Wyobraźmy sobie np. ogromną bibliotekę utworów muzycznych, które mają nazwy plików utworzone zgodnie z jakimś kluczem i kilku (kilkunastu) programistów rozproszonych po kraju (czy świecie). Wszystko kręci się w MVC, a SI ma frontend, backend i zapewne kilka innych aplikacji pod maską.

Z jednej strony najlepiej stworzyć klasę "Plik" czy "Utwór Muzyczny", która między innymi odpowiadałaby za weryfikację/tworzenie właściwej nazwy pliku. Ale jest kilka problemów: w różnych częściach aplikacji z czasem mogą powstać "bliźniacze" klasy o rożnych odpowiedzialnościach, ale z niewielką częścią wspólną --- niech to będzie nazwa pliku. Jedne tylko odczytują, inne konwertują inne dystrybuują. Z czasem algorytm tworzenia nazw może ulec zmianie. Programiści mogą podlegać rotacji itp.

Jest też inny problem. Tworząc nieco opasłą klasę i powołując setki dynamicznych obiektów do życia tylko po to by pogenerować właściwe nazwy plików ryzykujemy zarżnięciem aplikacji w godzinach szczytu.

Wszystko to może być przesłanką do zastosowania jednak helpera "użyczającego" właściwego algorytmu generowania/weryfikacji nazwy pliku na różnych poziomach SI.

Temat: model, helper czy klasa?

Jarek Żeliński:
Olek, Boski Obiekt z zasady jest Singletonem :)))

Owszem, Boski Obiekt i Singleton nie jedno piwo wypili razem ;) Ale zasadniczo Singleton jest wzorcem, a Boski Obiekt antywzorcem. Wszystko zależy do czego używamy Singletona :)

Temat: model, helper czy klasa?

Aleksander Olszewski:
Zgadzam się z Tobą Jarku, że projektowanie poprzez odpowiedzialność jest najlepszym punktem wyjścia, jednakże...

[...]

Wyobraźmy sobie np. ogromną bibliotekę utworów muzycznych, które mają nazwy plików utworzone zgodnie z jakimś kluczem i kilku (kilkunastu) programistów rozproszonych po kraju (czy świecie). Wszystko kręci się w MVC, a SI ma frontend, backend i zapewne kilka innych aplikacji pod maską.

Z jednej strony najlepiej stworzyć klasę "Plik" czy "Utwór Muzyczny", która między innymi odpowiadałaby za weryfikację/tworzenie właściwej nazwy pliku. Ale jest kilka problemów: w różnych częściach aplikacji z czasem mogą powstać "bliźniacze" klasy o rożnych odpowiedzialnościach, ale z niewielką częścią wspólną --- niech to będzie nazwa pliku. Jedne tylko odczytują, inne konwertują inne dystrybuują. Z czasem algorytm tworzenia nazw może ulec zmianie. Programiści mogą podlegać rotacji itp.

Jest też inny problem. Tworząc nieco opasłą klasę i powołując setki dynamicznych obiektów do życia tylko po to by pogenerować właściwe nazwy plików ryzykujemy zarżnięciem aplikacji w godzinach szczytu.

Wszystko to może być przesłanką do zastosowania jednak helpera "użyczającego" właściwego algorytmu generowania/weryfikacji nazwy pliku na różnych poziomach SI.

rozwiązanie:
- nazwa pliku jako ValueObject

Temat: model, helper czy klasa?

Aleksander Olszewski:

Jarek Żeliński:
Olek, Boski Obiekt z zasady jest Singletonem :)))

Owszem, Boski Obiekt i Singleton nie jedno piwo wypili razem ;) Ale zasadniczo Singleton jest wzorcem, a Boski Obiekt antywzorcem. Wszystko zależy do czego używamy Singletona :)

No to chyba uznamy, że Boski Obiekt to Singel :)

a tak poważnie, to praktycznie każdy system napisany w paradygmacie funkcyjnym to taki BoskiObiekt...Jarek Żeliński edytował(a) ten post dnia 20.03.12 o godzinie 13:22

Temat: model, helper czy klasa?

Niekonieczne. Do widoku (kontrolki) można przekazać obiekt (o ustalonym interface) który dopiero w momencie odwołania do konkretnej metody / property będzie pobierać dane. Tzn. można wykorzystać mechanizm lazy loading.

"lazy loading" to chyba raczej pociąganie z bazy... (repozytorium...)???? a vidoc nie ma kontaktu z utrwalaniem...

Po raz kolejny: niekoniecznie :)
Implementacja interfejsu "Car" po stronie klienta może jedynie wywoływać metody serwisu.
Np: W momencie kiedy ktoś (jakaś kontrolka) się dobiera do gettera "GetPicture" implementacja OD po stornie klienta zwraca wynik wywołania serwisowej metody GetCarPicture(int carId).

Dodatkowo taki wynik można cache-ować czyli mamy lazy loading tyle, że po stronie klienta i dla serwisu (a nie DB).

Nie wiem, może ModelView komuś przypadł do gustu, ale wg. mnie ten pattern wg. mnie ma dwie poważne wady:
2 (poważna). Ciężko stworzyć hierarchię między klasami ModelView

???

....kontynuując: jeśli nie ma hierarchii, abstrakcji, interfejsów klas a to znaczy, że kod jest powielany.

Klasy ModelView są tworzone na potrzeby konkretnych widoków i w związku z tym nie pozostają w żadnej relacji dziedziczenia między sobą. Tak jak helpery, singeltony i inne takie .. To jest sprzeczne z ideą projektowania obiektowego.

Temat: model, helper czy klasa?

Klasy ModelView są tworzone na potrzeby konkretnych widoków i w związku z tym nie pozostają w żadnej relacji dziedziczenia między sobą. Tak jak helpery, singeltony i inne takie .. To jest sprzeczne z ideą projektowania obiektowego.

dziedziczenie nie jest warunkiem obiektowości... np. model dziedziny w zasadzie nie zawiera dziedziczenia...

skąd teza, że warunkiem obiektowości jest dziedziczenie?

Temat: model, helper czy klasa?

Jarek Żeliński:

Klasy ModelView są tworzone na potrzeby konkretnych widoków i w związku z tym nie pozostają w żadnej relacji dziedziczenia między sobą. Tak jak helpery, singeltony i inne takie .. To jest sprzeczne z ideą projektowania obiektowego.

dziedziczenie nie jest warunkiem obiektowości... np. model dziedziny w zasadzie nie zawiera dziedziczenia...

skąd teza, że warunkiem obiektowości jest dziedziczenie?

Ja bym powiedział, że idea obiektowości to niezależne obiekty (aktorzy) wymieniający między sobą komunikaty poprzez dobrze zdefiniowane interfejsy / protokoły.

Moim zdaniem najczystszą tego implementacją jest... internet - mamy aktorów takich jak np serwery i przeglądarki i zdefiniowany interfejs - protokół HTTP, każdy z aktorów jest niezależny od drugiego i wszystko działa cacy ;)Wojciech Soczyński edytował(a) ten post dnia 20.03.12 o godzinie 23:11

Temat: model, helper czy klasa?

Jakub Wojt:
...
Klasy ModelView są tworzone na potrzeby konkretnych widoków i w związku z tym nie pozostają w żadnej relacji dziedziczenia między sobą. Tak jak helpery, singeltony i inne takie .. To jest sprzeczne z ideą projektowania obiektowego.

Kto powiedział, że Singleton nie może mieć dziedzica czy rodzica? Powiem więcej: dziecko po Singletonie w cale nie musi być Singletonem. Może być np. Multitonem, bo jak inaczej realizujesz acocjację o licznośc 1..n?

Temat: model, helper czy klasa?

Klasy ModelView są tworzone na potrzeby konkretnych widoków i w związku z tym nie pozostają w żadnej relacji dziedziczenia między sobą. Tak jak helpery, singeltony i inne takie .. To jest sprzeczne z ideą projektowania obiektowego.

Kto powiedział, że Singleton nie może mieć dziedzica czy rodzica?

http://en.wikipedia.org/wiki/Singleton_pattern#Impleme...
Konstruktor musi być prywatny (nie można dziedziczyć) więc Singletonu nie można dziedziczyć.

Temat: model, helper czy klasa?

http://en.wikipedia.org/wiki/Singleton_pattern#Impleme...
Konstruktor musi być prywatny (nie można dziedziczyć) więc Singletonu nie można dziedziczyć.

ale nie używamy konstruktorów tylko fabryki :)

Temat: model, helper czy klasa?

Jakub Wojt:

Klasy ModelView są tworzone na potrzeby konkretnych widoków i w związku z tym nie pozostają w żadnej relacji dziedziczenia między sobą. Tak jak helpery, singeltony i inne takie .. To jest sprzeczne z ideą projektowania obiektowego.

Kto powiedział, że Singleton nie może mieć dziedzica czy rodzica?

http://en.wikipedia.org/wiki/Singleton_pattern#Impleme...
Konstruktor musi być prywatny (nie można dziedziczyć) więc Singletonu nie można dziedziczyć.

Słyszałeś o przesłanianiu? Pozatym brak konstruktra nie jest powodem uniemożliwiającym dziedziczenie.Aleksander Olszewski edytował(a) ten post dnia 21.03.12 o godzinie 15:41

Temat: model, helper czy klasa?

Aleksander Olszewski:

Jakub Wojt:

Klasy ModelView są tworzone na potrzeby konkretnych widoków i w związku z tym nie pozostają w żadnej relacji dziedziczenia między sobą. Tak jak helpery, singeltony i inne takie .. To jest sprzeczne z ideą projektowania obiektowego.

Kto powiedział, że Singleton nie może mieć dziedzica czy rodzica?

http://en.wikipedia.org/wiki/Singleton_pattern#Impleme...
Konstruktor musi być prywatny (nie można dziedziczyć) więc Singletonu nie można dziedziczyć.

Słyszałeś o przesłanianiu? Pozatym brak konstruktra nie jest powodem uniemożliwiającym dziedziczenie.

Tak naprawdę, to nie ma logicznych powodów by w ogóle używać singletonów, więc cała dyskusja jest z góry jałowa :). Użycie Singletona świadczy o złej architekturze systemu.Wojciech Soczyński edytował(a) ten post dnia 21.03.12 o godzinie 16:36

Temat: model, helper czy klasa?

Tak naprawdę, to nie ma logicznych powodów by w ogóle używać singletonów, więc cała dyskusja jest z góry jałowa :). Użycie Singletona świadczy o złej architekturze systemu.

jeżeli wyeliminujemy użycie konstruktorów to fakt... ale klasy usługowe mogą być inicjowane (ożywiane) np. pierwszym użyciem danego przypadku użycia (scenariusza), jak panować nad tym, czy dana klasa usługowa jest jedna dla wszystkich czy każdy ma swoją?Jarek Żeliński edytował(a) ten post dnia 21.03.12 o godzinie 16:42

Temat: model, helper czy klasa?

Jarek Żeliński:

Tak naprawdę, to nie ma logicznych powodów by w ogóle używać singletonów, więc cała dyskusja jest z góry jałowa :). Użycie Singletona świadczy o złej architekturze systemu.

jeżeli wyeliminujemy użycie konstruktorów to fakt... ale klasy usługowe mogą być inicjowane (ożywiane) np. pierwszym użyciem danego przypadku użycia (scenariusza), jak panować nad tym, czy dana klasa usługowa jest jedna dla wszystkich czy każdy ma swoją?

Hm, kontener DI ?