Dynamiczny DTO, chciałbym podyskutować

0

Chciałbym przedyskutować pewnego rodzaju wzorzec ilustrując Javą i Groovym, ale w pełni możliwe w innych językach, choćby wzorzec (jak każdy wzorzec, przez niektórych uważany za antywzorzec) ActiveRecord.

Wyobraźmy sobie klasę, która nie ma zbyt mocnego wyposażenia w metody, jej sensem jest przenoszenie danych. Ma dynamiczną listę wartości pól i dynamiczny sposób uzyskiwania metadanych (refleksji).
w Groovym najlepszym przedstawicielem tego myślenia jest Expando, ale zalążek tkwi w GroovyObject
http://docs.groovy-lang.org/latest/html/api/groovy/util/Expando.html
http://docs.groovy-lang.org/latest/html/api/groovy/lang/GroovyObject.html
w Javie / C# by to była klasa która posiada Map / Dictionary <string,object> i coś do metadanych

Przed moimi oczami jest potencjał wdrożeniowy, tj customizowany kod dla pojedynczego klienta, takie deteosy, pracujący w kontekście "silnika" (type-safe) z firmy softwarowej.

Dlaczego tak popularny (???) wzorzec jest tak rzadko do znalezienia w necie? Czy przyczyną jest zdanie powyżej - jest to kod poufny, zamknięty w serwerach firm? Nie jest aż tak użyteczny?
Co powinienem przemyśleć?

0

W C# od jakichś 10 lat jest ExpandoObject i dynamic. Tylko tego się raczej nie używa, bo strata na wydajności i wypieprzaniu się w runtime zamiast na etapie kompilacji przewyższa wszystkie zyski.

0

No takie rzeczy to prędzej w dynamicznie typowanych językach :-P

7

Przed moimi oczami jest potencjał wdrożeniowy, tj customizowany kod dla pojedynczego klienta, takie deteosy, pracujący w kontekście "silnika" (type-safe) z firmy softwarowej.

dieheretic.jpg

Czyli mamy język kompilowany (C#/Java itd), ale kombinujemy jak tu olać kompilator, żeby móc sobie wywalić serwer dopiero na produkcji.

Niestety takie patterny są używane - nazywam to Hashtable oriented programming. I niestety miałem z tym do czynienia. Praktyka jest taka, że co chwila leci NullPointerException w logach, bo kolega robiący metodę confirmOrder( HashMap allparams) { } powiedział, że jako klucz trzeba też wrzucić login użytkownia, ale nikt nie uważał na spotkaniu. Dzieki hashomi wszytko się nadal kompiluje, a że testów nie ma, to jest fajnie.

Ten pattern to dobra recepta na : jak pisać kujowy kod i jeszcze móc zrzucić na wszystkich winę, że nie uważaja na spotkaniach i nie czytają javadoców (bo w Javadocu przed klasą stoi jasno, że każda metoda wymaga takiego parametru w hashmapie`).

Ogólnie: tak sie pisze w javascripcie. Niektórzy to lubią. Osobiście preferuję użycie kompilatora. (poza tym robię zbyt dużo literówek, żeby móc operowac na kluczach w hashmapach).

Jeśli natomiast wrzucasz do tej customizacji tylko jakis worek z polami, które Cię nie interesują i nigdzie w kodzie ich nie używasz (pytanie: po co są wtedy) - to oczywiście tak się robi czasem i nie jest to tragedia.

W jednym systemie mam taki worek (mape), na pola wpisywane przez użytkowników, które potem są obrabiane w enginie BPMN (tyle, że tylko przepychamy problem. Błędy, żo ktoś zapomniał coś ustawić wychodzą w procesorze BPMN, a nie w kodzie java).

EDIT:
Połączenie takiego dynamizmu i dużej (dużo wiekszej niż normalnie) ilości testów działa i jest całkiem stabilne. Choć refaktoring jest bolesny. W typowanych jezykach jednak IDE potrafi dużo więcej pomóc przy grubszych zmianach.

1 użytkowników online, w tym zalogowanych: 0, gości: 1