Přejít k navigační liště

Zdroják » Různé » Proč stojí objektové programování za starou belu

Proč stojí objektové programování za starou belu

Články Různé

Překlad staršího textu Why OO Sucks of Joe Armstronga.

Nálepky:

Překlad článku Why OO Sucks, který napsal Joe Armstrong. S jeho laskavým svolením jsem text přeložil do češtiny pod licencí Creative Commons by-nc-sa. Text původně vyšel na blogu překladatele.

Když mi poprvé předs­ta­vili myšlenku OOP (objek­tově orien­to­vané progra­mování), tak jsem byl skeptický, ale nevěděl jsem proč. Prostě jsem jen cítil, že je to špatně. OOP se stalo velmi populárním (později vysvětlím proč) a jeho kritika byla něco jako klení v kostele. OOP se stalo něčím, co každý slušný jazyk musel mít.

Jak se Erlang stával populár­nějším, ptali se nás: „Je Erlang objek­tově orien­to­vaný?“ Pocho­pi­telně správná odpověď byla: „Samozřejmě, že ne!“, ale neříkali jsem to nahlas. Takže jsme vymys­leli důmys­lnou odpověď, která měla zanechat dojem, že Erlang je (tak trochu) objek­tově orien­to­vaný (když budete hodně mávat rukama) ale ne doopravdy (pokud jste poslou­chali, co jsme ve skuteč­nosti říkali, a pečlivě četli drobné písmo).

Vzpomínám si na úvodní přednášku, kterou tehdy měl ředitel francouzské IBM na sedmém ročníku konfe­rence IEEE Logic programming v Paříži. IBM prolog přidal spoustu objek­tově orien­to­vaných rozšíření. Na moji otázku proč, odpověděl:

Naši zákaz­níci chtěli objek­tově orien­to­vaný prolog, tak jsme udělali objek­tově orien­to­vaný prolog.

Jak snadné, bez výčitek svědomí, bez sebez­py­tování, bez ptaní se: „Je to správná věc?“

Proč stojí objektové programování za starou belu

Moje zásadní námitky k OOP se týkají základ­ních myšle­nek. Některé z nich vyjme­nuji a přidám k nim svoje námitky.

Námitka 1 – Datové struktury a funkce by se neměly míchat

Objekty svazují funkce a datové struk­tury v neděli­telné jednotky. Domnívám se, že jde o základní chybu, protože datové struk­tury a funkce patří do úplně odlišných světů. Proč?

  • Funkce něco dělají. Mají vstupy a výstupy. Tyto vstupy a výstupy jsou datové struktury, které jsou modifikované funkcemi. Ve většině jazycích jsou funkce vytvořeny sekvencí imperativů: „Udělej tohle a pak tohle…“ Abyste porozuměli funkcím, musíte porozumět pořadí, v jakém věci vykonají.
  • Datové struktury prostě jsou. Nedělají vůbec nic. Jsou ve své podstatě deklarativní. Porozumění datové struktuře je mnohem snazší než porozumění funkci.

Funkce jsou vnímány jako černé skříňky, které trans­for­mují vstup do výstupu. Jestliže rozumím vstupu a výstupu, tak rozumím funkci. To ovšem nezna­mená, že zvládnu funkci napsat.

Funkce jsou obvykle chápány jako části počítač­ového systému, jejichž úkolem je trans­for­movat datové struk­tury typu T1 na datové struk­tury typu T2.

Jelikož jsou funkce a datové struk­tury úplně odlišné živoč­išné druhy, je zásadní chybou zamykat je do jedné klece.

Námitka 2 – Všechno musí být objekt

Vezměme si čas. V OOP jazycích musí čas být objekt. Ale v ne-OOP jazycích je čas instancí datového typu. Například v Erlangu je mnoho různých variant času, který může být jasně a jedno­značně speci­fi­ko­vaný násle­dujícím způsobem:

-deftype day() = 1..31.
-deftype month() = 1..12.
-deftype year() = int().
-deftype hour() = 1..24.
-deftype minute() = 1..60.
-deftype second() = 1..60.
-deftype abstime() = {abstime, year(), month(), day(), hour(), min(), sec()}.
-deftype hms() = {hms, hour(), min(), sec()}.
...

Všimněte si, že tyto definice nepatří žádnému konkrét­nímu objektu. Jsou všudypřítomné a datové struk­tury repre­zen­tující čas můžou být zpracovány jakou­koliv funkcí v systému.

Neexi­s­tují žádné souvi­sející metody.

Námitka 3 – V OOP jsou definice datových typů rozprostřené úplně všude

V OOP patří definice datových typů objek­tům, takže nemůžu najít všechny definice datových typů na jednom místě. V Erlangu nebo C můžu definovat všechny své datové typy v jediném hlavič­kovém souboru nebo data dictio­nary. V OOP to nejde – datové typy jsou rozpros­třené všude možně.

Dovolte mi uvést příklad. Předpok­ládejme, že chci definovat všudypřítomnou datovou struk­turu. Všudypřítomný datový typ je datový typ, který se objevuje na všech místech v systému.

Jak lisp programátoři již dlouhou dobu vědí, je lepší mít menší počet všudypřítom­ných datových typů a velké množství malých funkcí, které s nimi pracují, než mít velký počet datových typů a malé množství funkcí, které s nimi pracují.

Všudypřítomná datová struk­tura je něco jako spojový seznam, pole nebo hash tabulka či pokroč­i­lejší objekt jako čas, datum nebo soubor.

V OOP si musím vybrat nějaký základní objekt, ve kterém všudypřítomnou datovou struk­turu definuju. Všechny ostatní objekty, které chtějí tuto datovou struk­turu použít, musí dědit od tohoto objektu. Předpok­ládejme, že chci vytvořit něco jako objekt čas. Kam patří a do jakého objektu?

Námitka 4 – Objekty mají private stav

Stav je příčinou všeho zla. V jednot­livých funkcích s vedlejším efektem bychom se mu měli vyhnout. Zatímco v progra­mo­vacích jazycích je stav nežádoucí, reálný svět jím oplývá. Velmi mě zajímá stav mého bankov­ního účtu, a když si vložím nebo vyberu peníze, tak očekávám, že stav mého bankov­ního účtu bude správně upraven.

Stav existuje v reálném světě. Co by tedy měly progra­mo­vací jazyky poskyt­nou, aby s ním šlo pracovat?

  • OOP říká: „Skryj stav před programátorem.“ Stav je skrytý a viditelný jen přes funkce.
  • Konvenční programovací jazyky (C, Pascal) říkají, že viditelnost proměnných se stavem je kontrolována pravidly oblasti platnosti (scope) jazyka.
  • Čistě deklarativní jazyky říkají, že stav neexistuje.

Globální stav systému vstupuje do všech funkcí a ze všech funkcí vystu­puje. Mecha­nismy jako monády (pro funkcionální jazyky) a DCG (logické jazyky) jsou použity ke skrytí stavu před programátory, takže mohou progra­mo­vat, jako kdyby na stavu nezáleželo, ale pokud by to bylo nutné, tak mají ke stavu plný přístup.

Možnost skrýt stav před programátorem, kterou vybralo OOP, je tou nejhorší možnou. Místo toho, aby stav odhalili a pokusili se najít způsob, jak minima­li­zovat potíže s ním spojené, tak ho skryjí.

Proč bylo OOP tak populární?

  • Důvod 1 – Domnívali jsme se, že je snadné se ho naučit.
  • Důvod 2 – Domnívali jsme se, že znovupoužitelnost kódu bude snazší.
  • Důvod 3 – Byl kolem toho humbuk.
  • Důvod 4 – Vytvořilo to nové odvětví softwarového průmyslu.

Nevidím důkaz pro 1 a 2. Důvody 3 a 4 se zdají být hnací silou této techno­lo­gie. Jestliže techno­logie jazyka je tak špatná, že vytvoří nové průmys­lové odvětví, aby vyřešila problémy, které sama způso­bila, tak to musí být dobrý nápad pro chlápky, kteří chtějí vydělat peníze.

To je skutečná hnací síla OOP.

Související

Přeložený článek pochází ze série textů Object Oriented Programming is Inherently Harmful a vyvolal řadu reakcí, jako hlavní zmiňme text Martina Vilcanse No, that’s not why OO sucks.

Komentáře

Subscribe
Upozornit na
guest
29 Komentářů
Nejstarší
Nejnovější Most Voted
Inline Feedbacks
View all comments
harrison314

Dnes je moderne (pseudo) funkcionalne programovanie (tlacene JS a Reaktom), no ked clovek robil v cistictich funkcionalnych jazokych ako Haskell, tak to pseuofunkcionalne programovanie v JS ma od neho neuveritelne daleko.

V podlenej dobe si vsimam heitu OOP, ale vzdy je to ako v tomto clanku a vychadza z aboslutneho nepochopenia OOP principov ako celku. Samozrjeme dobre funckionalne programovanie je lepsie ako zle obejktove.
No ten clanok vychadza z absolutneho nepochopenia OOP, vsteky vyhrady sa daju riesit, alebo nie su problem, alebo ich riesi IDE.

Ono treba este podktnut, ze OOP a FP v najcitejsej podobe je prakticky nepouzitelne, preto kazdy pouzivany jezak, je do istej miery miltiparadigmovy.

jaro123

No nevim, ja to teda radeji resim bez IDE

harrison314

Tym IDE som narazal na hlavickove suborry spomenute v clanku, ked chcem vidiet vsteky definicie pokope a prehrabavat sa v nich, nebudem ich pisat do jedneho suboru ako 80-tych rokoch, ale IDE mi ich vie ukazat pokope (napr. Visual Studio a Object Explorer).

rssreader

Nevím proč se vůbec někdo obtěžuje s překladem takového neobjektivního blábolu nějakého nesoudného či možná jen zhrzeného programátora?

Martin Hassman

Protože když autor Erlangu napíše něco, s čím zásadně nesouhlasím, stojí za to se zamyslet. Vypadá to, že se plete, a možná se opravdu plete, ale pravděpodobně je v programování zkušenější než já, tak je to příležitost k růstu. Mému, když se jí chopím.

Pako

Zejména když autor už to sám dávno (před lety) smazal a sám teď píše že o celé věci přemýšlí hodně jinak. Jako historický dokument o úvahách autora snad… bez kontextu ovšem bezcenné.

Martin Hassman

Nesouhlasím. Svět není binární. Lidé se vyvíjí. Autor text neodmítá, naopak byl rád za jeho překlad a šíření.

harrison314

Autor prezentuje len svoje nazory, no neargumentuje, tak napriklad:

Námitka 1 – Datové struktury a funkce by se neměly míchat
– akosi nechape co to OOP vlastne je, a aky ma zmysl pouzivanie objektov, polymorfizmus,…

Námitka 2 – Všechno musí být objekt – nie nemusi, mnoho jazykov je multiparadigmovych C++, C#, kde nemusi byt vsteko objekt. Plus je to rovnaky argument ako, ze vo funkcionalnom programovani musi byt vsetko funkcia (v cistejsich FP ide hodnotu zamenit za funkciu vracajucu tuto hodnotu).

Námitka 3 – V OOP jsou definice datových typů rozprostřené úplně všude – toto je uz fakt trochu moc, vid. argument zo stringom, tam nie je pravda snad ani jedna veta.

Námitka 4 – Objekty mají private stav – ano maju, je to jeden zo zakladnych principov OOP, co ma mnoho pozitiv (bezpecnejsie API, abstrakcia,…).

Proč bylo OOP tak populární? – tiez len subjektivne nazory, pokial ich nepodlozi niecim.

Andreaw Fean

No, ty taky zrovna moc neargumentuješ.

Námitka 4 – Objekty mají private stav – ano maju, je to jeden zo zakladnych principov OOP, co ma mnoho pozitiv (bezpecnejsie API, abstrakcia,…).

Ano, a já absolutně souhlasím s autorem, že to je obrovská bolest a fakt blbej nápad.

Oldis

„Všechny ostatní objekty, které chtějí tuto datovou struk­turu použít, musí dědit od tohoto objektu.“
Tak když je takhle postavené tvrzení, které není pravdivé tak bohužel to argumentaci jako celek dost sráží.
String: nemusim od něj dědit a přece s nim můžu pracovat.
Mýt všechny typy v jednom hlavičkovém souboru (hlavičkové soubory jsou přežitek) považuju za nesmysl.
Stav je všudy přítomný, například v registrech v ram atd…

hellx

Toto všechno pramení z nepochopení OOP do hloubky. OOP je pouze nástroj pro vyjádření vztahů v reálném světě. Existují metodiky, jak postupovat. Tyto metodiky – např DomainDrivenDesign – mají své implementace – např. CQRS/ES. Potom OOP začíný být opravdu zajímavé a začne jednomu dávat smysl, protože se v něm vyskytují i prvky funcionálního programování. A pojmy jako base object, interface, potomek naprosto ustupují do pozadí, protože se už zabýváte Designem systému. Přestáváte oddělovat Architekturu, Analýzu a samotné programování. A když váš Design systému je Hnaný Doménou (DDD), tak systém bude dělat co má (což je opravdu velice vzácná stav :D).
Výsledkem potom může být systém, jeho dílčí části jsou materializovány (chápej vyvíjeny) různými týmy, pomocí různých jazyků i přístupů a ještě k tomu opravdu jako microServices (ne nesmyslně nano services nebo naopak monoliths). Takto vyvíjený systém má šanci na to uspět, škálovat a v neposlední řadě být udržovatelný a rozšiřitelný.

Zdeněk Merta
  1. Domain-Driven Design není metodika. Je to soubor principů a praktik.
    Nemá žádnou souvislost s OOP kromě toho, že Eric Evans ve své době implementoval taktické vzory pomocí OOP.
  2. CQRS/ES nejsou implementací DDD. Jedná se o nezávislé techniky. Opět nemají souvislost s OOP. ES je dokonce čistě funkcionální a dá se vyjádřit několika funkcemi. Implementace pomocí OOP je samozřejmě taky možná.
ivoszz

Jen technická poznámka, docela by mne zajímala vaše definice metodiky. Podle mne je metodika právě soubor principů a praktik vytvářející uzavřený a smysluplný celek.

spindl

Přesně tak, to je přece metodika, taky mě to zarazilo. :D

Bystroushaak

Jo, v tomhle kontextu to dává smysl. Já jsem si právě u čtení článku říkal, že autor nekritizuje OOP, ale ten zprasený subset, který razí Java a podobné jazyky. Třeba ve Smalltalku / Selfu to celé funguje jinak a ta kritika ani nedává moc smysl.

murdej

stejně jako vidlička je naprd když je potřeba se pořeba vytáhnout si kamínek z oka. Nejsou špatné metodiky, antiparenty, … ale jen nevhodně zvolené pro daný účel.
Třeba teď nedávno jsem narazil na problém který by se dal nejlépe vyřešit pomocí goto, ikdyž je goto „nejhorší peklahodný programátorský hřích“

Filip.Jirsak

„Ve většině jazycích jsou funkce vytvořeny“ → má být „ve většině jazyků“

Jenom čtenář

Když pominu dětinskost . . .

Proč bylo OOP tak populární?

Důvod 1 – Domníval**i** jsem se, že je snadné se ho naučit.
Důvod 2 – Domníval**i** jsem se, že znovupoužitelnost kódu bude snazší.
Důvod 3 – Byl kolem toho humbuk.
Důvod 4 – Vytvořilo to nové odvětví softwarového průmyslu.

„Byl kolem toho humbuk“ – to jako vážně?

Fajn, někdo něco napíše, proč ne, ale tak trocha soudnosti při výběru toho co přeložit, by asi neškodila – možná by bylo dobré zaměřit se na kvalitu výstupu než na životopis osobnosti.

ondra-m

Aneb vždy záleží na typu problému či osobní preferenci.

Vláďa Macek

Podle mě je článek příliš citově zabarven a ukazuje nedostatečný nadhled a zkušenost s tím, co kritizuju. Jak už tady psali komentující. Překlad místy zanáší určitou kostrbatost vyjáření, přesto za něj děkuju. Bylo by skvělé, kdyby si čtenáří i komentující v česku víc zvykali na to, že když je někde něco publikováno, tak to není prosazování jediného správného názoru, ale POLEMIKA, výkop k diskusi směřující ideálně ke konsenzu. Taková správná polemika s Armstrongem, který byl opravdu na pár místech argumentačně dle mě mimo, je v odkazovaném článku „No, that’s not why OO sucks“, který se mi líbil.
Děkuju, mějte se fajn.

Martin Hassman

Vláďo, díky! <3 8-)

Pr

Tohle bylo řečeno moc pěkně

Jenom čtenář

IMO polemika je jedna věc, posílat dál (zde překladem) věci typu „Hnacím motorem bylo: byl kolem toho humbuk“ je věc druhá. Samozřejmě ať si píše kdo chce a překládá kdo chce co chce, držím palce, když to pak ale vystaví veřejně, ať se ale nediví že to ledaskomu ani k nějaké polemice nepřipadá.

tacoberu

Mě to pomohlo si utřídit myšlenky. Zkušenosti, které s OOP mám, ale neumím je dobře vyjádřit. Možná to autor nevyjádřil nejlépe, možná se o tom dá polemizovat, každopádně já mu přizvukuju.

Andre

Suhlasim, je to cele iba humbuk aspon z mojho pohladu 20tich rokov embedded/fullstack programatora
Uzitocnost OOP sa prejavi len v okrajovych situaciach. Jeho nevyhody su vsak brutalne hlavne v prostredi, kde je treba optimalizovat prostriedky a výkon, Dokazom je „evolucia“ Windowsu. a vysledok, ze dnes tu po vyse 20 rokoch mame systemove poziadavky, ktore raketovo vystrelili nahor o niekolko radov a pritom je to stale iba premalovany Win95.
Znovapouzitelnost – to je krasny a zvelicovany mytus, ktory sa ale v praxi takmer nevyskytuje. Pri zakladani noveho projektu je znovapouzitelnost otazka programovej kultury a nie objektoveho pristupu,
V zasade OOP ma zmysel, pre urychlenie a pohodlie prace programatora, nie pre vyslednu kvalitu SW kde je podla mna vacsinou na skodu.

old rich

souhlas se vsim, jedine ne s vetou: ‚V zasade OOP ma zmysel, pre urychlenie a pohodlie prace programatora,‘.

Ve srovnani s cim? Ja nevidim vyhody vubec nikde. Kdyz nam v 90. letech slibovali, jak budou programy bezpecne, znovupouzitelne a snadeji zhotovitelne, tak mela rada programatoru nadeji. Dnes mame vsichni tu jistotu, ze se nic z toho nenaplnilo. Programy napsane OO padaji zrovna tak jako jine, projekty jsou zrovna tak drahe a proflakle jak projekty, kde se programuje proceduralne atd. Nic nez ten humbuk.

lambda_kalkulus

Dnesni programatori neprogramuju objektovo, skutocne oop tu bolo v 90tych rokoch, ked si programator vyskladal program v Delphi z komponent (nevizualny objekt) a controlov (vizualny potomok komponentu). Chytil som TButton nastavil som mu vlastnost text a buttonu sa zmenil text nastavil som mu vlastnost color na red a buttonu sa zmenila farba na cervenu. Vtedy som mal jediny krat v zivote pocit ze programujem objektovo boli to krasne casy a trvalo to 5 rokov… ked som chcel vlastnu komponentu stacilo dedit od triedy TComponent, TControl alebo od hociktorej inej komponenty, ktoru som si chcel upravit. Existovalo x databázových, alebo internetovych komponent, ktore som len naskladal na formular poprepajal medzi sebou a program bol hotovy. Potom ale prisla Java, C# a PHP a tie koncept oop uplne zabili, z objektov sa stali len obycajne moduly a programatori ktori predtým programovali v procedurálnych jazykoch – koncept oop vôbec nepochopili. Ono pri pisani server side aplikacii sa to pochopit ani moc neda. Takze programatori programuju doteraz proceduralne pricom vyuzivaju moznosti objektových jazykov a nazyvaju to objektovym programovanim.

Milan Křepelka

Velmi se mýlíte. Java i C# jsou plně objektové jazyky. Zmiňujete jednu malou část celé škály „SW palety barev“. A navíc k tomu ještě dost nedobře. Kdybyste třeba vedle sebe dal VCL a WF(Windows Forms). Jen velmi těžko byste hledal „10 rozdílů“

Enum a statická analýza kódu

Mám jednu univerzální radu pro začínající programátorty. V učení sice neexistují rychlé zkratky, ovšem tuhle radu můžete snadno začít používat a zrychlit tak tempo učení. Tou tajemnou ingrediencí je statická analýza kódu. Ukážeme si to na příkladu enum.

Pocta C64

Za prvopočátek své programátorské kariéry vděčím počítači Commodore 64. Tehdy jsem genialitu návrhu nemohl docenit. Dnes dokážu lehce nahlédnout pod pokličku. Chtěl bych se o to s vámi podělit a vzdát mu hold.