Konferencja programistyczna pewnego (nie)szczęsnego systemu ERP.
Jeden z gości dość dużo mówił, wchodził w dyskusje z devami ERP, miał swoje zdanie na każdy temat. Zaklasyfikowałem go (nie wiem, czy słusznie) jako "architecture astronaut". Patterny! Abstrakcje! #YouAreGonnaNeedIt! On by był chyba pierwszym do napisania FizzBuzz Enterprise Edition.
Kłócił się z devami ERP o to, że według niego ich system był wybrakowany pod względem serializacji. Oczywiście serializować dane tam można, ale nie tak prosto, jak on by tego chciał. A on by chciał, żeby w API ERP była metoda na zasadzie string Kontrahent.Serialize(). I już. Bo on jest „wielkim fanem serializacji”.
Devowie ERP tego podejścia nie uznawali. „Ale jak chcesz zserializować kontrahenta? Co np. chcesz zrobić z przypisanymi do niego dokumentami handlowymi, też je zserializować? Olać? A może zachować tylko id tych dokumentów w bazie danych?” Facet wszedł w słowo: „Ja nie chcę wiedzieć, jak chcę zserializować kontrahenta. Ja chcę zserializować kontrahenta!”
Mnie to w sumie nie obchodzi, ja akurat potrzeby serializacji kontrahenta nie odczuwam. Ale temat jakoś nie może mi dać spokoju.
Czy jest przyjęte, że wszystko można / powinno być można zserializować „i już”?
Mnie się zdaje, że ten facet był typowym przykładem pogoni za „podręcznikowymi” sposobami rozwiązywania problemów, jednak bez zrozumienia po co się dane patterny stosuje (więc chce je pchać wszędzie, nawet tam, gdzie nie mają zastosowania) i w jaki sposób. Na przykład wie, że jest takie coś jak DTO, które się serializuje i że to jest przydatne. Wie też, że jest takie coś jak tajemnica implementacji: osoba korzystająca z danego interfejsu nie powinna interesować się, jak funkcjonalność tego interfejsu jest zaimplementowana. Połączył jedno z drugim i wyszedł mu potworek: „Ja nie chcę wiedzieć, jak zserializować kontrahenta. Ja chcę zserializować kontrahenta!” Zapomniał albo nie zrozumiał, że DTO, które podlega serializacji, należy wpierw napisać i to on ma obowiązek to zrobić. Nie ma czegoś takiego jak serializacja wyjęta z kontekstu - trzeba wiedzieć co i po co się serializuje. Przykład z dokumentami handlowymi był dobry: Jeśli facet chce zserializować kontrahenta tylko na potrzeby pracy z tym systemem ERP (nie wyobrażam sobie po co, ale może ma jakiś powód) to zastąpienie dokumentów handlowych referencjami w bazie danych być może byłoby sensowne. Jeśli wysyła tego kontrahenta do zewnętrznego systemu ale w obrębie tego samego przedsiębiorstwa, to być może ma sens przepisanie dokumentów do zserializowanych danych (ale wtedy facet musi interesować się formatem, do którego kontrahent będzie zserializowany!), ale jeśli wysyła kontrahenta na zewnątrz firmy, to dokumentów handlowych (znów być może) absolutnie nie wolno mu załączać.
Tak bym to przynajmniej widział...
Ale znam siebie na tyle, że wiem, że często kompletnie nie rozumiem wzorców i moje sądy w tym zakresie bywają całkowicie błędne. Dlatego zastanawiam się poważnie, czy moja ocena jest tu trafna, czy nie?
Czy istnieje coś takiego jak serializacja „i już”, bez pytania jak coś zserializować, jak chciał tamten gość?
Czy też – tak jak mi by się zdawało – serializacja zawsze winna odbywać się właśnie z pomyślunkiem, jak chce się coś zserializować, po co i jaki program będzie to czytał i w związku z tym konieczność pisania własnego DTO albo złożonej konfiguracji wbudowanych w zewnętrzne API serializowatorów nie jest niczym zdrożnym?
