poznáme.itVývoj WEBovMutable vs. Immutable

Mutable vs. Immutable

Mutable vs. Immutable 2

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.

Mutable vs. Immutable 4Kľúč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.

Mutable vs. Immutable 6Nemeniteľ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 6 200 ITečkárov dostáva správy e-mailom. Nemusíš sa báť, nie každé ráno. Len občasne.

Súhlasím so spracovaním mojich osobných údajov. ( Viac informácií. )

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

Zdeno Jašek
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.

Čítaj ďalej: