IT rekvalifikace s garancí práce. Seniorní programátoři vydělávají až 160 000 Kč/měsíc a rekvalifikace je prvním krokem. Zjisti, jak na to!
Hledáme nové posily do ITnetwork týmu. Podívej se na volné pozice a přidej se do nejagilnější firmy na trhu - Více informací.

23. diel - Najčastejšie chyby Java nováčikov - Vieš pomenovať objekty?

V minulej lekcii, OOP v Jave naposledy - Boxing, balíčky a doplnenie , sme sa zaoberali balíčkami a ďalšími OOP konštrukciami.

V dnešnom Java tutoriále si ukážeme prvé dobré praktiky pre objektovo orientované programovanie v Jave. Pozri sa, či nerobíš jednu z najčastejších chýb.

Slovo senior programátora

David Čápka - Objektovo orientované programovanie v Jave - Objektovo orientované programovanie v Jave

Gratulujem k zdolaniu základnej problematiky objektovo orientovaného programovania! 🏆 Dostal si sa k záchytnému bodu, v ktorom sa trochu vydýchame a ukážeme si, ako správne použiť nadobudnuté informácie, než sa pustíme do ďalších. Materiál pre dnešnú lekciu som zostavil na základe 20-ročných skúseností s programovaním a jej obsah bude mať zásadný vplyv na tvoje ohodnotenie na trhu práce.

Miliónové straty

O dobrých praktikách sme sa už bavili v kurze Základná konštrukcia jazyka Java a vieme, že neprehľadné programy nie sú vôbec žiadna malichernosť. Sú totiž:

  • Nezrozumiteľné pre ostatných - Keď tím 5 programátorov, každý s platom 100.000 Sk mesačne, strávi 20% pracovnej doby lúštením kódu, stojí to ročne 1.2 milióna Sk!
  • Náchylné k chybám - Tržby aj malých e-shopov sú mesačne obvykle v miliónoch korún, 1 deň nefunkčnosti teda stoja majiteľa stovky tisíc Sk, dodávateľovi hrozia nemalé zmluvné pokuty.
  • Prakticky nerozšíriteľné - V súčasnej funkčnosti sa už nikto nevyzná a nemožno ju rozšíriť. Programátorský tím o niekoľkých ľuďoch musí vytvoriť aplikáciu znova, sme opäť v miliónoch Sk.
  • Netestovateľné, nezabezpečené a takto by sme mohli pokračovať.
Niet pochýb, že dobré praktiky sú pre vývoj softvéru v tíme úplne zásadné a následky ich porušenia potom úplne fatálne.

Ako správne pomenovávať triedy, atribúty a metódy?

Vieme vytvárať množstvo nových objektových konštrukcií, v programoch nám vzniká množstvo nových identifikátorov (mien). V dnešnej lekcii sa budeme zaoberať tým, ako "objektové súčiastky" našich aplikácií správne pomenovať, aby boli prehľadné.

Motivačný príklad

K doktorovi príde pacient a hovorí mu, že má problém so svojím orgánom Presouvat. Nefunguje mu bota. Pacient sa zdá byť nejaký popletený a doktorovi trvá pomerne dlho, kým z neho dostane, že ho pichá v päte a preto si nemôže obuť ani topánku. Keď konečne vypustí pacienta z ordinácie, zistí, že bol súčasťou skupiny a takých ich tam ešte čaká niekoľko desiatok.

Objektovo orientované programovanie v Jave - Objektovo orientované programovanie v Jave

Pozrime sa ešte na druhý príbeh. Programátorovi pridelí program, ktorý spadne s chybou v triede PresouvatData, metóda data(). Program sa zdá byť nejaký popletený a programátorovi trvá dlho, než zistí, že ide o triedu importujúcu dáta z externej zálohy a že sa prvýkrát musí ručne zavolať metóda pracuj(), ktorá import vykoná. Keď chybu konečne opraví, objaví sa ďalšia a zistí, že v programe je niekoľko desiatok tried a metód, z ktorých názvu vôbec nespozná, čo robia.

Určite vidíme paralelu týchto dvoch príbehov. Zatiaľ čo u ľudského tela by nás asi ťažko napadlo hovoriť o orgáne "presúvať" a funkciu "topánka", v programoch bohužiaľ nie je taký problém naraziť na objekty pomenované ako deje a funkcie pomenované ako veci, aj keď je princíp úplne rovnaký. Niet divu, že si Indescriptive naming vyslúžilo svoje miesto v šestici najhorších programátorských praktík STUPID.

Pomenovanie tried

Triedy definujú objekty, z ktorých je aplikácia zložená. Z toho vyplýva niekoľko triviálnych pravidiel. Názvy tried:

  • sú podstatné mená! - Jedná sa o jednotlivé počítateľné objekty bez ohľadu na to, koľko objektov od triedy potom vytvoríme.
  • nie sú názvy dejov - Ide o objekty (veci). Triedy teda nemôžeme nazvať napr. PraceSeSouborem alebo Vypisovani, ale napr. SpravceSouboru alebo Vypisovac (alebo ešte lepšie UzivatelskeRozhrani, pretože zriedka kedy tvoríme celú triedu len na vypísanie niečoho).
  • začínajú s veľkým písmenom - Každé ďalšie slovo má veľké písmeno (notácia) PascalCase. Je tak vidieť, že ide o všeobecnú triedu a nie o jej konkrétnu inštanciu.
  • pomenované podľa toho, akú súčasť programu reprezentujú, čo nemusí byť vždy rovnaké, ako to, čo vo vnútri robia.
Ukážme si niekoľko príkladov:

\---

\--- \---

Pokiaľ narazíte na program, kde sa trieda volá PraceSeSouborem, jeho autor si pravdepodobne len vygooglil, že kód sa píše do class bez toho, aby tušil, že tým založil nejaký objekt.

Triedy v množnom čísle

V množnom čísle pomenovávame triedy veľmi zriedka. V Jave takto nájdeme napr. triedu Arrays. Od tej nevytvárame inštancie a používame ju len pre prácu s inštanciami triedy Array, teda s poľami. Pole zotriedime napr. ako:

Osobne by mi oveľa väčší zmysel dávalo, aby tieto metódy mala na sebe priamo trieda Array a písali sme teda:

Autori Javy pravdepodobne nechceli triedu Array príliš zložitú a tak pre niektoré metódy vytvorili túto druhú triedu. Výsledný prínos je diskutabilný. My triedy v množnom čísle väčšinou deklarovať nebudeme.

Pomenovanie tried v angličtine

Základné kurzy sú na ITnetwork po slovensky, aby boli lepšie stráviteľné. Kódy tých pokročilých sú rovnako ako reálne obchodné aplikácie po anglicky. Pre anglické názvy tried platí samozrejme to isté, čo sme povedali vyššie. Môžeme však ľahko urobiť nasledujúce chyby:

  • Jednotné čísla - Keď v slovenčine pomenujeme triedu pracujúcu s autami SpravceAut, mohol by sa ponúkať anglický preklad CarsManager. Správne je však CarManager, jednotné číslo, pretože Car tu funguje ako prídavné meno.
  • Poradie slov - Na rozdiel od slovenčiny je podstatné meno na konci súslovia, správca áut teda nie je ManagerCars alebo ManageCars, ale CarManager. Cesta k súboru nie je PathFile (čo by bol cestový súbor), ale FilePath a pod.
V angličtine sa u tried často používa koncovka -er, napr. TaskRunner, podľa toho, čo trieda robí.

Ukážme si pár príkladov:

\---

\--- \---

Pomenovanie atribútov

Atribúty sú "premenné" danej triedy. Pre ich pomenovanie teda platia úplne tie isté zásady ako pre premenné, ktoré si už detailne vysvetľovali v lekcii Najčastejšie chyby Java nováčikov - Vieš pomenovať premenné?.

Základným pravidlom opäť je, že atribúty pomenovávame podľa toho, čo je v nich uložené. Názov atribútu chápeme v kontexte názvu triedy a nemusí teda dávať zmysel sám o sebe. Z jazykového hľadiska sú názvy atribútov:

  • podstatné mená (jmeno, zamestnanci, ...)
  • prídavné mená (vypnuty, odeslano, ...)
Pripomeňme si tu aj ostatné zásady:
  • všetky atribúty pomenovávame buď česky bez diakritiky alebo anglicky, ale nie kombináciou týchto jazykov
  • viacslovné atribúty pomenovávame pomocou notácie camelCase
  • ak atribút obsahuje kolekciu s viacerými hodnotami (napr. pole alebo List), je jeho názov v množnom čísle
Ukážme si opäť nejaké príklady názvov atribútov tried:

\---

\--- \---

Pomenovanie metód a parametrov

Metódy označujú deje, ich názov obsahuje teda sloveso ! Môže ísť o:

  • prikazovací tvar (nacti(), nastavId()) - Metóda prevažne vykonáva nejakú činnosť a jej výsledok môže alebo nemusí vracať. Nevolíme infinitív, napr. nacitat().
  • opýtací tvar - Metódou sa prevažne pýtame na nejakú hodnotu, než aby sme chceli vykonať nejakú akciu (slovensky napr. vratJmeno() alebo jeVypnuty() pre premenné typu boolean, anglicky napr. getRank(). Už vieme, že takýmto metódam hovoríme gettery.
Metódy pomenovávame podľa toho, čo robia! Vyhýbame sa neurčitým názvom ako pracuj(), akce(), run() apod.

Ukážme si príklady:

\---

\--- \---

Parametre metód

Parameter metódy je premenná a preto pre ich názov platia tie isté pravidlá, ako pre premenné a atribúty (napríklad nikdy nepomenujeme parameter param:) ). Je tu však jedna dôležitá vec na uváženie a to je použitie dvojitej negácie. Ukážme si posledný príklad:

\---

\--- \---

Kto z vás na prvú dobrú dokáže povedať, či sú v prvom variante s odovzdaním hodnoty false kľúče povolené? Všetko je zas o ľudskom mozgu, ktorý nie je zvyknutý fungovať pod dvojakou negáciou. Volíme teda skôr druhý variant.

V nasledujúcej lekcii, Ako správne rozdeliť Java aplikácie do tried - SRP a SoC , si vysvetlíme dobré praktiky SRP (Single Responsibility Principle) a SoC (Separation of Concerns). Nahryzneme aj tému závislostí.


 

Predchádzajúci článok
OOP v Jave naposledy - Boxing, balíčky a doplnenie
Všetky články v sekcii
Objektovo orientované programovanie v Jave
Preskočiť článok
(neodporúčame)
Ako správne rozdeliť Java aplikácie do tried - SRP a SoC
Článok pre vás napísal David Hartinger
Avatar
Užívateľské hodnotenie:
Ešte nikto nehodnotil, buď prvý!
David je zakladatelem ITnetwork a programování se profesionálně věnuje 15 let. Má rád Nirvanu, nemovitosti a svobodu podnikání.
Unicorn university David sa informačné technológie naučil na Unicorn University - prestížnej súkromnej vysokej škole IT a ekonómie.
Aktivity