Vlákno názorů ke zprávičce Kritika objektového programování: je to katastrofa? od PaRi - Po letech praxe mohu zodpovědně prohlásit, že největší...
-
Po letech praxe mohu zodpovědně prohlásit, že největší kritici OOP pocházejí z tábora lidí, co nemají o objektovém programování valného povědomí, případně jsou totální chaotici.
No a taky není od věci si vybírat k určité práci ten správný nástroj. Kleštěmi sice hřebík zatluču, ale kladívko bude lepší, že...
22. 7. 2019, 21:40 editováno autorem komentáře
-
Amen.
Standardni blabol haskelloveho jehovisty.
Nejprve sestavim sadu strawmanu, otresne blbych architektonickych examplu a tuto hloupost svedu na OOP paradigma.
Pak pridam starou dobrou ignoranci, zmatlam dohromady class level encapsulaci a application business stav, problem je samozrejme v OOP, protoze architekt byl tak pitomy, ze neslysel ani o MVC a roztahal business stav aplikace po ruznych tridach, jak ho napadlo.Je zbytecne to dale rozmazavat, pregnantne to vyjadril ve sve reakci Vlad Balin:
https://medium.com/@gaperton/let-me-start-from-the-less-obvious-thing-7f49e87a45ca -
Z pohledu zadavatelů není důležité hodnocení, jestli je neschopný programátor, technologie či styl programování. Důležitý je výsledek v průměrném případě. OOP, když se umí, je asi lepší. Podmína "když se umí" je v praxi těžce dosažitelná.
Myslím, že 90 % hamburgerů připravených doma na grilu překoná McDonald's. Domácí gril je OOP. McD ale potřebuje miliony zaměstnanců po celém světě, kteří dokáží splácat žemli s karbanátkem během tří minut, s minimem odpadu a s přesně stanoveným množstvím ingrediencí. To je procedurálníá programování. Umožňuje dopřát si mírně nadprůměrný burger za rozumnou cenu a s minimálním rizikem excesů (zapomenuté suroviny, moc omáček apod.).
Z mého pohledu: OOP má mnohem vyšší vstupní práh pro programátora. Odvádí pozornost od algoritmizace k sémantice. Rychlé zásahy v kódu jsou složité, protože je potřeba nastudovat široké okolí. Špatně navržený objekt je nečitelný a jeho refaktorování zabere hodně času.
Dobrým příkladem procedurálního programování by mohlo být jádro Linuxu. Neobjektovost nic neubírá ani na jeho čitelnosti a rozšiřitelnosti.
-
„Z mého pohledu: OOP má mnohem vyšší vstupní práh pro programátora.“
Dle zkušeností Smalltalkařů pouze u procedurálních/strukturovaných programátorů (to je bohužel většina, což vysvětluje tento názor; taky jsem to zažil), u lidí nezasažených těmito myšlenkovými konstrukcemi NAOPAK nižší.„Rychlé zásahy v kódu jsou složité, protože je potřeba nastudovat široké okolí.“
Je to PŘESNĚ NAOPAK - je-li objekt uzavřenou jednotkou s definovaým rozhraním a funkcionalitou, není třeba znalosti jeho vnitřku, naopak to bývá kontraproduktivní.„Špatně navržený objekt je nečitelný a jeho refaktorování zabere hodně času.“
To přece platí o každém kódu. Nedodržuje-li objektový návrh princip odpovědnosti a související stavy i logika překračují hranice objektů, dostáváte se na úroveň procedurálního programování. -
Dobre je srovnat si kod napr. v OpenBSD a OS/X, to je znacny extrem. Musim rict, ze ty objektove veci OS/X temer nejsem schopen pochopit (trva to strasne dlouho a clovek jen zasne co se tam deje), kdezto kod OpenBSD staci jen prolitnout a je hned jasno.
Nicmene neni to asi jen o OOP: Kod System V ci V7 Unixu src/uts je pomerne ciste C, ale nektere casti (mm, alokator) jsou i tak naprosto necitelne. Nebo veci ve Windows, ty jsou nektere navrzeny tak slozite (asi postupem casu jak to dobastlovali), ze i pres ciste C a po precteni dokumentace nejsem schopen s jistotou rici jak se neco bude chovat.
-
Ja teraz obcasne pozeram zdrojove kody isteho RTOS, ktory je pisany v osekanom C89 a je to zatial asi najnecitatelnejsi kus kodu, ktory som kedy videl hned po zdrojakoch MS-DOSu 6, ktory bol pisany v assembleri. Codebase tej veci ani nie ze zavratne velka, radovo maximalne niekolko MB.
Predtym som pracoval na projekte napisanom v C++11, ktory mal radovo miliony riadkov zdrojovych kodov a bolo to pomerne slusne citatelne. Clovek si sice obcas preskakal cez viacero tried kym zistil, co je kde v typovom systeme implementovane, ale kod samotny sa cital a chapal celkom dobre (vzhladom k velkosti codebase).
OOP/neOOP naozaj na inherentnu citatelnost kodu nema vplyv. To ako si ho niektore jazyky urobia ale mat moze. Kazdopadne najvacsi vplyv na to ma indent style a stabna kultura programatorov.
-
L.Stříbrný podporovatel
To mi připomíná staré programátorské přísloví: Neexistuje jazyk, ve kterém by se nedal napsat špatný program.
-
Ondra Satai NekolaZlatý podporovatelAle často se zapomíná na to, že v některých jazycích je to o dost snažší a psat špatné programy je součástí jejich kulturního dědictví...
