[r.....j]

siedzę w 2 letnim projekcie prowadzonym przez zasiedzianych ludzi, praktycznie wszystko co się da jest oparte na hashmapach i podawaniu klucza z palca, i teraz moje pytanie czy tak się pisało 10-15 lat temu w javie?
#programowanie #java

[dupaztrupa]

@rekoj:cały czas tak się pisze :( zależy kto robi. Z 5 lat temu pracowałem w pic rel, ale to był projekt gdzie 15k linijek kodu polsko-angielskiego wcale nie dziwiło.

Ocenzurowałem nazwy obiektów, były polskie i mogły trochę wskazywać na klienta

[globalbus]

@rekoj: w innych językach dalej się tak robi :P
Patent z mapą nie jest taki zły, o ile klucz jest enumeratorem lub stałą z jednego miejsca (więc można w IDE dać find usages). Camel głównie w ten sposób działa (Exchange to worek z dwoma mapami, headers i properties).

[Ridicz]

@dupaztrupa:

[PoteznyMagWody]

@globalbus: nie patrzyłbym na biblioteki apache jako wzór czystego kodu. Robilem w cxf i tam cokolwiek znaleźć to powodzenia, jedynie pozostaje grzebac w kodzie zrodlowym ktory wyglada jak gowno, no i oczywiscie tez wszystko opearte na mapach tyle ze nawet bez generyk. I mowie tu o wersji 3.x

[globalbus]

@PoteznyMagWody: znajdowanie czegokolwiek tam jest kijowe głównie dlatego, że to jest message oriented architecture i przepływ pomiędzy komponentami nie jest oczywisty. A że CXF nie ma praktycznie dokumentacji, to zupełnie odrębna kwestia. Ma za to jedną ważną zaletę - zapierdziela.

[r.....j]

@globalbus: mmm enum luksus którego mi brakuje, tak samo dokumentacja, wieloktornie marnuje czas w pracy na dochodzenie jak dana funkcjonalność ma działać

[kriemann]

@globalbus: patent z mapą może nie jest zły, ale z mapą z mapą z mapą ... w mapie w mapie w mapie to nie patent, tylko jakaś abominacja.

[globalbus]

@kriemann: a co do tego nie mam wątpliwości. Choć widziałem użycie, głównie do czegoś co obsługuje "generyczne jsony/yamle". Pod spodem to właśnie zagnieżdżone mapy. Jak już ktoś się decyduje na takie brzydactwa, to już lepiej w groovy to napisać.

[Saly]

Camel głównie w ten sposób działa (Exchange to worek z dwoma mapami, headers i properties).

@globalbus: a to imo zły przykład. Camel tak mocno ingeruje w bazę kodową, że zamiast uproszczonej integracji dostajemy upośledzony meta język, w którym system typów opiera się o stringi. Do małych rzeczy spoko, ale prędzej czy później kod się rozrasta, dochodzi coraz więcej logiki i z Javy robi się bash.

[Saly]

Choć widziałem użycie, głównie do czegoś co obsługuje "generyczne jsony/yamle". Pod spodem to właśnie zagnieżdżone mapy. Jak już ktoś się decyduje na takie brzydactwa, to już lepiej w groovy to napisać.

@globalbus: to jest akurat fajny przykład, gdzie takie coś się przydaje. Jakieś małe modyfikacje jsona czy yamla robi się dużo prościej w pythonie, bo te formaty bardzo dobrze mapują się na typowanie dynamiczne

[globalbus]

@Saly: Ja camela używam tylko w wersji Java DSL, gdzie takie konstrukcje są ograniczone do minimum (w zasadzie jedyny string, z którego się korzysta, to removeHeaders("*")). Camel w XML to zło.

[Saly]

@globalbus: a to jest inny rak. W tym co pisałem chodzi mi o to, że pomiędzy kolejnymi klockami w camelu nie ma silnych typów, tylko headers i message, przez co pozbywamy się jakiejkolwiek statycznej analizy

[globalbus]

@Saly: a to tak, to są klasyczne problemy dynamicznego typowania, czyli przeniesienie błędów kompilacji do runtime. Receptę znam jedną, enumeratory i stałe. Plus trzeba sobie wypracować konwencję w ramach projektu. Takie podejście daje radę.