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 (překlad uvolňuji pod licencí Creative Commons by-nc-sa).

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.

Funkcím obvykle porozumíme pozorováním, že jsou věcmi v počítač­ovém systému, jejichž úkolem je trans­for­movat datové struk­tury typu T1 do 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í, tak 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ánlí 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 jsem se, že je snadné se ho naučit.
  • Důvod 2 - Domnívali 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.

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í