Ono to v praxi funguje tak, že za černou krabičku často někdo nese zodpovědnost. Pak když černá krabička nefunguje, honíme k zodpovědnosti autora. To je prostě stejné, jako v reálném světě. V programování často větší logické celky končí tam, kam dosáhne časový a paměťový akční rádius daného programátora. (co stihne ještě držet v paměti a časově zvládat udržovat a vyvíjet). Jenže tito programátoři jsou jako bohové. Mají své dílo, tomu rozumí, nikdo jiný mu nerozumí, jsou nenahraditelní. Pokud program převedeme na malé jednotky v OOP, kde jedna krabička by se s náročností na pochopení dala přirovnat k jedné hodině studia zdrojáků, pak nenahraditelnost těchto programátorů povážlivě trpí. V týmu se to dělá tak, že všechny objekty se hodí na hromadu, rozdělí se mezi programátory, každý má na starost nějakou oblast. Přestane-li to zvládat, část objektu se převede na jiného programátora. Větší programové celky pak řeší senior programátoři, kteří ale stejně tak vidí jen černé krabičky, a nezajímá je vnitřek. Pochopení fungování těchto celků na základě krabiček (objektů) má pak podobnou časovou náročnost.
Podle mne je báječné na OOP, že program se skládá z atomů, minimálních objektů. Mám objekty, které jsou na dva řádky. Jsou to pořád objekty. Pořád se s nimi pracuje stejně (snadno). Pokud by daný problém nebyl řešen objektově, mnohem hůř by se pak s problémem pracovalo.
(-: Mimochodem Linux shell je objektový. Každá spuštěná aplikace má stdin a stdout a parametry na příkazové řádce. Kolikrát člověk vidí, jak nějaká linuxová aplikace je jen spolupráce několika různých malých prográmků. Ty jsou taky černé krabičky a autoři těchto aplikací nevědí, a ani často nechtějí vědět, co se skrývá unvnitř :-)
Názor k článku
Štěpán Škrob: Horkým kandidátem byl WebKit, ale vybrali jsme Gecko
