Mutable vs. Immutable

1
699

S nástupom funkcionálnych jazykov sa častokrát objavuje požiadavka na nemeniteľnosť atribútov objektu – immutability. Tento článok upozorňuje na to, kde sú hranice využitia nemeniteľných objektov pri objektovo-orientovanom programovaní.

Pre potreby zmien v softvéri je kľúčová schopnosť postaviť softvér na modeli, ktorý čo najvernejšie odráža realitu. V objektovom modeli sa častokrát vyskytujú nemeniteľné objekty, pre ktoré je využitie funkcionálneho programovania vhodné a rozumné.

Používanie funkcionálnych jazykov však občas tlačí programátorov do nevhodných modelov. Potreba zachovať „čistú funkciu“ vedie k spôsobu programovania, v ktorom sú všetky objekty nemeniteľné – immutable. Vzniká tak model, ktorý neodráža realitu. Stráca sa hlavná výhoda objektovo-orientovaného programovania: držať znalosti o doméne pomocou známych doménových pojmov v modeli. Programovanie sa tak stáva technickou záležitosťou odtrhnutou od reality.

Kľúčovým pravidlom pre rozhodnutie o nemeniteľnosti objektu je odpoveď na otázku: „Čo tvorí identitu objektu?“ Napríklad trieda Pacient s atribútmi meno, priezvisko a rodné číslo je v doméne evidencie pacientov u lekára príkladom meniteľného objektu. Identita pacienta totiž nie je daná tým, ako sa volá, ani tým, aké má rodné číslo. Ak pacient zmení meno, priezvisko, alebo rodné číslo, stále je to ten istý človek, ktorý bol na návšteve u lekára minulý mesiac, je alergický na peľ a berie lieky na srdce. Identita pacienta nezávisí od jeho atribútov. Ak sa dvaja pacienti rovnako volajú a nedopatrením majú aj rovnaké rodné číslo, stále sú to dvaja rôzni pacienti.

V objektovom svete je identita objektu typu „Pacient“ daná referenciou na inštanciu triedy. V databázovom svete má záznam o pacientovi priradený jednoznačný identifikátor. Objekt typu Pacient je teda modifikovateľný, pretože v doméne to takto funguje. V doméne si pacient môže zmeniť meno aj rodné číslo a práve preto musí aj objekt typu Pacient v správnom modeli takúto zmenu umožniť.

Požiadavka na to, aby bol objekt typu Pacient nemeniteľný, vedie k nesprávnemu modelu.

Nemeniteľným objektom môže byť napríklad adresa pacienta. Pacient sa síce môže presťahovať, ale v takom prípade sa nemení názov ulice, kde býval. Ale naopak: pacientovi je priradená nová adresa, ktorá existovala aj predtým, než sa presťahoval. A stará adresa sa nijako nezmení, ostáva pôvodná. Adresa je príkladom nemeniteľného objektu, ktorý je definovaný svojimi atribútmi. Ak dvaja ľudia bývajú na rovnakom popisnom čísle, na rovnakej ulici, v rovnakom meste a v rovnakom štáte, bývajú na rovnakej adrese. Obaja môžu mať vo svojich záznamoch priradenú tú istú inštanciu triedy Adresa. Alebo môžu mať priradené aj dve inštancie triedy Adresa, ktoré sú však zhodné – nemá zmysel medzi nimi rozlišovať.

Adresa je v uvedenom kontexte nemeniteľný objekt otvorený aplikovaniu funkcionálneho programovania.

Základným rozlišovacím prvkom medzi nemeniteľným a meniteľným objektom je identita objektu. Identita môže byť daná atribútmi – ako pri adrese. Vtedy je vhodné modelovať objekt ako nemeniteľný a zmenu atribútu nahradiť vznikom novej inštancie. Alebo identita môže vyplývať zo samotnej existencie bez ohľadu na hodnoty atribútov – ako pri pacientovi. Vtedy je vhodné modelovať objekt ako meniteľný a pripustiť zmenu atribútov s ohľadom na požiadavky v doméne.

Funkcionálne programovanie môže slúžiť ako vhodný doplnok k objektovému programovaniu. Článok osobitne o tejto téme je uvedený v odkaze. Na druhej strane  obmedzenie modelu len na nemeniteľné objekty znamená zavrhnutie objektového dizajnu a tým aj všetkých prínosov, ktoré objektovo-orientovaná paradigma prináša. Chýbajúci model domény, respektíve model nezodpovedajúci realite, môže priniesť do softvéru veľký zmätok v pojmoch a hlavne v nečakanom spôsobe fungovania softvéru, ktorý nezachránia ani benefity plynúce z funkcionálneho programovania.

Ďalšie zaujímavé odkazy k tejto téme nájdeš aj tu:

Dobrý článok? Chceš dostávať ďalšie?

Už viac ako 4 200 z vás dostáva správy e-mailom. Nemusíš sa báť, nie každé ráno. Len občasne.

Tvoj email neposkytneme 3tím stranám. Posielame naňho len informácie z robime.it. Kedykoľvek sa môžete odhlásiť.

Predchádzajúci článokBratislava bude po tretíkrát hostiť konferenciu PyCon
Ďalší článokŽeny v (IT) kurze
Zdeno Jašek
Pracujem ako Solution Architect vo firme PosAm a programovaním sa zaoberám takmer 30 rokov. Prešiel som jazykmi Basic, Assembler, Pascal, Object Pascal, Lisp, Prolog, Magic, MUMPS, Clipper, Paradox a Java, z ktorých najmilšia mi je Java. Pracoval som hlavne ako softvérový architekt, ale aj ako programátor, analytik, dizajnér a projektový manažér. Pri vývoji softvéru sa mi najviac páči navrhovanie objektového dizajnu – obzvlášť pre zložité aplikácie. Svoje blogy chcem zamerať na postupy pri vytváraní objektového návrhu aplikácie a ich technologickej realizácii v podobe hexagonálnej architektúry a microservices.
  • Zdeno

    Dobrý deň, vďaka za reakciu.

    Myslím, že ste článok pochopili správne a s podstatou Vašich tvrdení súhlasím. V článku som sa pokúšal nájsť práve tú hranicu hybridného prístupu, ktorý sa v Jave objavil od verzie 8 podporou pre funkcionálne programovanie. V mojom predchádzajúcom článku “Funkcionálne programovanie ako doplnok objektovo-orientovaného dizajnu” rozoberám práve tú druhú stranu mince – a poukazujem na to, že kombinovať funkcionálne programovanie s objektovo-orientovaným prístupom je celkom na mieste.

    Podstatu vidím práve v tom, aby si programátor či dizajnér uvedomil povahu problému, ktorý rieši a s ohľadom na to použil vhodný prístup. Teda, že technológia a štýl programovania by mal byť podriadený modelu, ktorý by zase mal byť podriadený doméne. Zároveň som sa snažil ukázať, že existujú prirodzené skupiny dát, pre ktoré je používanie čistých funkcií správne, a že existujú aj také dáta, ktoré sú meniteľné a teda z definície je používanie čistých funkcií nevhodné. Samozrejme, že sa tieto nevýhody dajú obísť istými technikami, ale už je to o ohýbaní a vlastne nevhodnom používaní.

    Cestu vidím osobne v rozumnom skĺbení oboch prístupoch než v zavrhnutí jedného z nich. Lebo v realite vidíme objekty, ktoré sa nemenia, ale aj tie, ktoré sa menia. Meniteľné objekty sú pre funkcionálne programovanie výzva, s ktorou sa musí vedieť vysporiadať. Objektovo-orientovaný prístup nemá problémy prirodzene manipulovať s oboma typmi.