Šta je ortogonalnost u programiranju i zbog čega je važna?

Nastavljamo serijal članaka baziranih na i inspirisanih klasičnim naslovom Pragmatični programer.

Prenosićemo glavne teme iz ove knjige (za koju vas svakako ohrabrujemo da je pročitate u celosti), uz primere iz prakse, bilo kao dopune glavnim temama ili kao zasebne članke. Pošaljite nam svoje kritike ili predloge za primere iz prakse ovde, a pogledajte i prethodne tekstove u rubrici Pragmatično programiranje.

Ortogonalnost je, složićemo se, malo rogobatna reč. Doduše, vredi je “svariti” i prihvatiti pošto opisuje jedan dosta koristan koncept u programiranju.

Onima koji su listali knjige iz geometrije pojam ortogonalnosti je poznat kao pojam koji opisuje dve prave u ravni koje se seku pod pravim uglom. Ako bismo takve dve prave posmatrali kao vektore rekli bismo da su nezavisne jer se projekcija bilo koje od te dve prave na drugu ne menja ako se pomeramo duž njih.

Ortogonalnost u kontekstu računarstva je princip koji omogućava da kreiramo sisteme koji se lako dizajniraju, razvijaju, testiraju i nadograđuju. Zbog toga o njoj možemo da govorimo kao o nezavisnosti i razdvajanju — dve ili više stvari su ortogonalne ako promene kod jedne ne utiču na ostale.

Suprotno od toga, neortogonalan sistem kakav je npr. helikopter, ima nekoliko kontrola od kojih svaka za sobom povlači sekundarne efekte. Kolektivnom palicom kontroliše se dizanje/spuštanje letelice, ali je pri tome potrebno poznavati i druge komande kojima se kontroliše položaj nosa i repa helikoptera kako se usled spuštanja ne bi desilo da helikopter krene nosom prema dole. Drugim rečima, radi se o kompleksnom sistemu u kome svaka promena ima uticaj na druge komande.

Zbog čega ortogonalnost?

Iz primera helikoptera očigledno je da neortogonalni sistemi za posledicu imaju složene situacije koje zahtevaju mnogo rada, teško se menjaju i kontrolišu. Pre svega zbog toga što u sistemima u kojima vlada međuzavisnost ne postoji mogućnost rada na jednom detalju, a da to nema uticaj na druge elemente sistema.

Iz tih razloga cilj je da se dizajniraju ortogonalni sistemi čije komponente su samostalne i imaju precizno definisanu svrhu. To sa sobom povlači da je moguće menjati jednu komponentu bez brige o tome kako će ona uticati na ostatak sistema.

Pored toga, ortogonalni sistemi donose dve velike prednosti u vidu povećane produktivnosti i umenjenog rizika.

O produktivnosti govorimo u smislu:

• lokalizovanja promena – lakše nam je da pišemo i testiramo manje samostalne komponente nego veliki blok koda, tj. ako imamo ortogonalni sistem nema potrebe da menjamo postojeći kod kada dodajemo novi,
• podsticanja korišćenja postojećeg koda – što je zavisnost među komponentama labavija lakše ih je kombinovati sa novim komponentama i koristiti u svrhu koja originalno nije bila u planu,
• kombinovanja komponenti – ako jedna komponenta izvršava m stvari, a druga n stvari i ortogonalne su, njihov rezultat izvršava m x n stvari.

Smanjenje rizika u ortogonalnim sistemima se ogleda u:

• tome što su mrtvi delovi koda izolovani – ako je neki modul „zaražen” teže će preneti simptome na ostatak sistema, a pri tome ga je i lakše uništiti i napisati nov,
• manjoj krhkosti – promene utiču samo na onu komponentu koju neposredno menjamo,
• lakšem testiranju – jednostavniji dizajn sistema uslovljava i lakše sprovođenje testova,
• većoj nezavisnosti – sistem neće biti direktno vezan za određeni proizvod, prodavca ili platformu jer će u slučaju ortogonalnog sistema interfejs biti izolovan.

Ortogonalnost u praksi

U praksi problem (ne)ortogonalnosti vidljiv je na mnogim mestima. Kako se autori Pragmatičnog programiranja bave njime u okviru projektnih timova, dizajna, alata i biblioteka, kodiranja, testiranja i dokumentacije, tako ćemo i mi. Pa, hajdemo redom.

Projektni timovi

Ukoliko su timovi organizovani tako da im se zadaci preklapaju, članovi tih timova često ne znaju koje su tačno njihove obaveze, a svaka promena zahteva uključenost velikog broja ljudi. Što više ljudi treba da bude uključeno u diskusiju pri svakoj promeni sistema, to su timovi manje ortogonalni.

Međutim, nije jednostavno organizovati timove tako da su svakome obaveze precizno utvrđene a preklapanja minimalna. Pošto organizacija timova zavisi od mnogo faktora, samo jedan od predloga je da se infrastruktura (baza podataka, komunikacioni interfejs i sl.) odvoji od same aplikacije, a za svaki deo infrastrukture i aplikacije oformi podtim.

Dizajn

U smislu dizajna preporučljivo je da sistem bude skup modula koji međusobno sarađuju i od kojih svaki implementira funkcionalnosti nezavisno od ostalih. Ovakva struktura komponenti često je organizovana u slojevima, gde svaki sloj obezbeđuje jedan nivo apstrakcije. To praktično znači da je korisnički interfejs jedan sloj, baza podataka drugi, framework treći, itd.

Ukoliko nismo sigurni da li je dizajn našeg sistema ortogonalan to možemo da proverimo postavljajući pitanje „Ako značajno promenimo zahteve iza određene funkcije, koliko modula će biti zahvaćeno ovom promenom?” U slučaju ortogonalnog sistema idealan (i gotovo nemoguć) odgovor je „Jedan”.

Uticaj ortogonalnosti na dizajn jasno se vidi na primeru promene interfejsa jednog kompleksnog sistema za nadgledanje i kontrolu toplane sa grafičkog na program kontrolisan govorom. Po ortogonalnim principima ovakva jedna promena uticala bi samo na module vezane za interfejs, ali ne i na samu logiku kontrole toplane.

Osim toga, ne treba samo moduli da budu nezavisni jedan od drugog, već čitav dizajn treba da bude što manje vezan za eksterne promene. Pri dizajnirajnju sistema treba imati na umu da nije dobro da se oslanjamo na stvari koje su eksterne i nisu pod našom kontrolom (npr. brojevi telefona kao identifikacija korisnika).

Alati i biblioteke

Kad smo već kod eksternih elemenata ortogonalnost je važno imati na umu i pri uvođenju alata i biblioteka. Pri tome se postavlja slično pitanje kao i ranije „Da li ovaj alat donosi promene u kod koje ne bi trebalo tu da se nađu?”

Odnosno, ako su objekti koji nastavljaju da postoje u okviru programa, funkcije ili nečeg trećeg (object persistance) transparentni, onda govorimo o ortogonalnosti. Konkretan primer bi mogao da bude upis u bazu. Ovim podaci ostaju trajno sačuvani, a transparentnost se odnosi na način na koji se bazom manipuliše iz programa.

Ideja je da se komunicira sa bazom na programskom jeziku na kom je napisan i softver, i da se uvede dodatni nivo apstrakcije (poput nekog ORM-a) koji će to omogućiti. Na primer – imaćemo biblioteku koja će omogućavati da u našem softveru ne kucamo SQL komande. Na taj način nismo vezani za SQL kao takav, već ga možemo sutra veoma lako zameniti, a da pritom ne menjamo naš kod.

O neortogonalnosti bismo govorili ako bi se od nas zahtevalo da kreiramo poseban način za pristup objektima. U skladu sa tim, prethodni primer bi bio neortogonalan ukoliko bi u softveru morali da kucamo SQL komande.

Kodiranje

Pri pisanju koda izlažemo se stalnom riziku od dupliranja funkcionalnosti, a da bismo to sprečili potrebno je da se vodimo sledećim pravilima:

• pisanje razdvojenog koda ili „stidljivog” koda koji drugim modulima ne otkriva ništa što nije neophodno i ne zavisi od implementacija drugih modula,
• izbegavanje korišćenja globalnih podataka – svaki put kada kod referencira globalne podatke on se vezuje za ostale komponente koje dele te podatke (u tom smislu, Singleton pattern pruža način da osiguramo da postoji samo jedna instanca objekta određene klase),
• izbegavanje sličnih funkcija, odnosno kreiranja setova funkcija sa npr. istim početkom ili krajem koda, a različitim centralnim algoritmima – zato stalno treba da refaktorišemo, tj. da budemo kritični prema svom kodu, ne propuštamo priliku da ga reorganizujemo kako bi mu se popravila struktura i ortogonalnost.

Testiranje

Ortogonalnost podrazumeva i lakše testiranje jer ako se vodimo njome možemo da testiramo sistem na nivou pojedinačnih modula. Takvo testiranje je lakše izvesti, pa se pragmatičnim programerima savetuje da u kod svakog modula ugrade jedinicu za testiranje i obezbede automatsko testiranje u toku procesa stvaranja. U isto vreme, testiranje je dobar način da otkrijemo da li je naš sistem ortogonalan. Ukoliko veliki deo sistema treba da učestvuje u testiranju jednog modula, naš sistem sigurno nije ortogonalan. Sličan slučaj je i sa ispravljanjem bagova.

Dokumentacija

Kada dokumentaciju posmatramo u kontekstu ortogonalnosti onda sadržaj i prezentaciju posmatramo kao dva nezavisna elementa, što u ovom kontekstu znači da bi trebalo da je moguće da značajno menjamo izgled a da ne dođe do promene u sadržaju.

Ortogonalnost i DRY

Princip koji smo ovde opisali je usko povezan sa DRY principom (Don’t Repeat Yourself) koji se temelji na minimalizovanju dupliranja u okviru sistema, a o kome je bilo reči u prethodnom tekstu iz ovog serijala. A kada poznajemo oba principa jasno nam je da se nezavisnost i minimalno dupliranje dovode do fleksibilnijih, lakše razumljivih i sistema jednostavnijih za testiranje, debagovanje i održavanje.