Podle me zasadni pristup v OOP, ktery dodal do tohoto modelovani tu spravnou konzistenci, je Inversion of Control. Diky IoC je totiz vlastne mozne redukovat OOP na jednoduchou plochou architekturu bez slozitych konstrukci, ktera nasledne tvori zaklad cele aplikace. Rozdeli to design na Funkce a Data. Tim se proste nikdy neda nic zkazit, je to VZDY prehledne. Nasledne sofistikovanejsi OOP konstrukce se pouzivaji, az pokud jsou vylozene k necemu prospesne. IoC umoznuje psat jednoduse a dava prostor otazce "Je tato OOP konstrukce (navrhovy vzor) pro aplikaci prospesnejsi, nez jednoduche IoC?" Pokud je, tak PAK JI TEPRVE pouziju, pokud ne (ve vetsine pripadu), pokracuje se v ploche IoC architekture. Zaroven je IoC takovy navrat ke korenum programovani, a to jsou prave ty Funkce a Data, ktere tu byly odjakziva. Dala by se na tom nakreslit (vyzivova) pyramida, kde spodni patro by nalezelo prave tomuto Funkce+Data designu.
Hosi, podle me tu resite veci, ktere se uz resily, v praxi v Jave (a obslehl to posleze C#) uz pred mnoha lety ve Spring frameworku.
A taky neni pravda, ze sofistikovane OOP konstrukce se k nicemu nehodi. Vsak se podivejte na Javu a .NET standardni knihovny, jaka to je nadhera. To je OOP vazeni! Srovnejte to s tema srackama co jsou v Javascriptu a pak tady pindejte neco o tom jak je OOP spatne. To je totiz typicke degenerativni binarni mysleni programatoru, ze nedokazou pochopit, ze neco DOzadekE neni bud a nebo, ale ze je tam ku*va SKALA. Kdyz si nejste vedomi toho, ze OOP je takto skalovatelne, tak tomu dpc NEROZUMITE.
1355 Odpovědí
129919 Zhlédnutí