Pravidelně se s OOP dostávám do problému, který se mi konečně podařilo podchytit a formalizovat. Zjistil jsem, že onen učebnicový příklad aplikace OOP sám o sobě smrdí. Jde o tohle:
Máme třídu User, která je v základu jakési POJO. No a je potřeba mít možnost uložit Usera do DB. Učebicové OOP říká, že máme dát metodu save() přímo do User. Na první pohled to zní logicky a elegantně, ale je to v principu kravina. Ten User bude mít vazby na další třídy, třeba na Company a Address atp. Co bude v metodě save(), když byl vytvořen rovněž i Company a Address objekt a User na to má návazovnost, tzn. nemá smysl vytvořit Usera bez nové Company a Address? Jenže v modetě save() v Userovi se přece nemůže zpracovávat i Company a Address, to je kravina.
To vede k architektuře, která z vysoka kálí na takovéto OOP paradigmata: Z User se stane obyčejné POJO, které bude mít dejme tomu závislost na jinačí POJO, a vytvoří se třída DBUtil, která bude pro jejich zpracování.
No a ta architektura je víte jaká? Daleko více připomíná procedurální programování než OOP: to POJO je datová struktura a to DBUtil je zpracovávající mechanismus.
Budiž mi důkazem, že v drtivě nejpoužívanějším frameworku Javy, ve Springu, to přesně takhle funguje. Třídy obsahující metody s jsou v podstatě všechny bezestavové a v jedné jediné instanci, úplně stejně jako kdyby to byly jen funkce. A POJO třídy jsou jediné, ze kterých se dělají instance.
No a proč to píšu, protože už si hodně dlouho, jak chuj, lámu hlavu s tím, proč kdykoliv když se snažím udělat si dobře architekturu aplikace, narazím na nejrůznější dilemata. Tak teď už to vím, jeden z těch hlavních důvodů je, že se snažím dělat OOP, a ono to přitom ani nejde!
136 Odpovědí
21672 Zhlédnutí