Czy istnieje coś takiego jak serializacja poza kontekstem?

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?

mi się wydaję, że jak najbardziej masz rację. W przeciwnym wypadku zwykły JSON.Stringify() rozwiązałby wszystkie problemy związane z serializacją. Wszystkiego.

Serializacja ma sens, ale w jakimś kontekście i jeśli jakiś obiekt jest duży, a domyślam się, że kontrahent takim jest, to często nie potrzebujemy wszystkich jego pól na raz tylko np adres kontrachenta albo informacje o płatnościach. Jeśli masz klasę/funkcję, która potrzebuje większości, albo wszystkich atrybutów kontrahent'a, to masz inny problem - zrodziłeś zapewne kolejny 40tysięcznik w kodzie :D

Moje skromne zdanie to "gość p... farmazony" ewentualnie nie potrafi powiedzieć o co mu chodzi, albo ty nie zrozumiałeś o co mu chodzi. Wewnątrz aplikacji mogę mieć obiekty, których nie potrzebuję serializować i nikomu nic do tego. Jak będę potrzebował takiej funkcji, to sobie ją napiszę, tak jak będę tego potrzebować, czyli będę miał w serializowanym obiekcie wyłącznie nip tego kontrahenta, albo pełne dane + zależności (np. faktury). Na zewnątrz systemu jak ma już ogromne znaczenie, bo jednak są pewne różnice pomiędzy deserializacją takigo JSON a Protobuff, więc zaszycie serializacji kontrahenta w nim samym jest absurdem, bo nie wiadomo na tym etapie jakie dokładnie wymagania ma spełniać ta funkcja. Czy wynikowy ciąg bajtów ma być czytelny dla człowieka, mieć małą objętość, być szybko przetwarzany i co najważniejsze w przypadku klasy z zewnętrznymi zależnościami - co właściwie ma być przedmiotem tej serializacji.

Nie klasyfikowałbym ludzi jako głupców, tylko dlatego, że ich nie rozumiem. Z tego co napisałeś wynika, że delikwent i developerzy nie dogadali się.
Za dużo skupienia na JAK (serializacja), a nie w JAKIM CELU. Może gość używa słowa "serializacja" w innym znaczeniu niż rozumieją dev?
Może widzi problemy, które system ma i nie potrafi tego efektywnie komunikować, a dev nie potrafili efektywnie zidentyfikować potrzeby zmian.

Czasem w systemach brakuje odpowiedniego API, bo nikt nie pomyślał, że systemy:

• nie działają w odosobnieniu, tylko coś się może się chcieć/musieć integrować z takim systemem
• nie działają jak puste pudełka od dnia 0, tylko klient chce przenieść dane, które ma w innych systemach (a API nie wspiera czegoś takiego, np. nie pozwala na utworzenie encji w określonym stanie / z datą wsteczną etc. )

(opcji że gość jest głupcem nie wykluczam :D )