Saa Tadi, dipl ing raunarske tehnike web site: http://sasatadic.net46.net/Crvanj e-mail: sasatadict@yahoo.

com Podgorica

SRP: The Single Responsibility Principle

Ovaj princip je opisan u radu Tom DeMarco i Meilir Page-Jones. Oni su ga nazvali kohezija. U nekim radovima se termin kohezija na nivou definicije paketa upotrebljava na mnogo suptilniji nain. Ipak, na nivou definicije klasa termin koehezija je u skladu sa definicijom ovog principa. Sutina ovog principa se moe iskazati kroz sljedeu definiciju: NE BI TREBALO NIKADA DA POSTOJI VIE OD JEDNOG RAZLOGA DA SE IZVRI PROMJENA KLASE Pretpostavimo da imamo klasu koja je odgovorna za dvije funkcionalnosti- odnosno da imamo klasu unutar koje su implementirane dvije razliite usluge za neki programski sistem. Sa stanovita potovanja SRP - Single Responsibility Principle-a, ovako definisana klasa nije korektna. Zato je bitno SRP ispotovati? Zato to implementacija prethodno pomenute dvije odgovornosti u jednoj klasi moe biti uzrok kasnijih potpuno nezavisnih izmjena u definiciji klase. Kada se pojavi novi zahtjev od strane korisnika za doradom jedne od funkcionalnosti implementacija tog zahtjeva se moe manifestovati kroz izmjenu ponaanja cijele klase odnosno i one druge funkcionalnosti. Ukoliko je klasa odgovorna za realizaciju vie od jedne funkcionalnosti, tada e postojati realna vjerovatnoa da se od strane korisnika ispostavljaju nezavisni zahtjevi za svaku od funkcionalnosti koja je implementirana u jednoj klasi. Ukoliko je klasa odgovorna za vie od jedne funkcionalnosti tada se odgovornosti na funkcionalnostima uzajamno mjeaju prepliu i postaju zavisne jedna od druge. Promjena u realizaciji jedne od odgovornosti moe da dovede do uzrono-posljedine izmjene u realizaciji neke od drugih odgovornosti u istoj klasi. Ovakav uticaj neminovno dovodi do kraha dizajnerskog rjeenja jer dovodi do nepredvidivih ponaanja sistema.

Slika 1: Vie od dvije odgovornosti u jednoj klasi

Na primjer, razmotrimo dizajn prezentiran na prethodnoj slici. Klasa Rectangle ima dvije metode. Jedna metoda crta kvadrat na GUI-u, druga metoda rauna veliinu zauzetog prostora kvadrata. Dvije razliite aplikacije koriste klasu Rectangle. Jedna aplikacija realizuje kompijutersku grafiku. Ona koristi Rectangle kao pomo u matematici geometrijskih oblika. Ova aplikacija nikada ne crta kvadrat na GUI. Druga aplikacija je izvorno grafika aplikacija. Ona se moe (ali i ne mora) baviti nekim elementima geometrijskog izraunavanja. Ona se definitivno i primarno bavi crtanjem kvardata na GUIu. Ovako dizajnirana klasa naruava SRP. Klasa Rectangle ima dvije odgovornosti. Prva je odgovornost za matematiko modeliranje geometrije kvardata. Druga odgovornost je crtanje kvadrata na monitoru raunara korisnikom interfejsu. Naruavanje SRP dovodi do nekoliko problema u dizajnerskom rjeenju: Prvo, ovakvo rjeenje nas primorava da moramo uvesti GUI u aplikaciju koja se bavi problematikom geometrijskih izraunavanja. Ukoliko je to C++ aplikacija, GUI bi trebao biti linkovan u ovu aplikaciju to dovodi do znaajne potronje kompijuterskog vremena, vremena potrebnog za kompajliranje ali i memorije. U JAVA aplikaciji .class file za GUI bi morao biti deploy-ovan na ciljnoj platformi. Drugo, ukoliko izmejene u grafikoj aplikaciji uzrokuju izmjenu u klasi Rectangle, izmjene e nas primorati da izvrimo rebuild a zatim ponovo testiramo i uradimo redeploy ComputationalGeometryApplication. Ukoliko bi zaboravili da ovo uradimo aplikacija kao cjelina moe da pukne iz nepredvidjenih razloga.

Bolje dizajnersko rjeenje je prikazano na slijedeoj slici:

Slika 2: Odovjene odgovornosti Ovaj dizajn prebacuje odgovornost vezanu za matematika izraunavanja u kompijuterskoj grafici iz klase Rectangle u klasu GeometricRectangle. Sada izmjene napravljene u nainu na koji se kvadrat iscrtava na GUI-u ne mogu uticati na ComputationalGeometryApplication.

ta je Responsibility?
U kontekstu Single Responsibility Principle mi definiemo odgovornost kao neta to moe biti razlog za promjenu u zahtjevu. Ukoliko moemo zamisliti vie od jednog razloga za

izmjenu u realizaciji klase tada ta klasa ima vie od jedne odgovornosti koja joj je delegirana. Ponekad je to teko uoiti. Mi smo prirodno prilagoeni da razmiljamo o odgovornosti u kontekstu grupa odgovornosti. Na primjer, razmotrimo interfejs koji se implementira u modemu.

Veina nas smatra da je ovakva definicija interfejsa savreno razumna. etiri funkcije koje ga deklariu su svakako funkcije koje pripadaju modemu. Na osnovu ovako definisanih funkcija uoavamo 2 odgovornosti u interfejsu modema. Prva odgovornost je vezana za ConnectionManagement, druga odgovornost je vezana za komunikaciju izmeu podataka. Dial i HangUp funkcije upravljaju konekcijama modema dok send i recv funkcije komuniciraju sa podacima. Pitanje je da li ove dvije odgovornosti trebaju biti dislocirane u dvije razliite klase? Gotovo je sigurno da trebaju. Dva seta funkcija gotovo da nemaju nita zajedniko. Svakako da e se one mjenjati zbog potpuno razliitih razloga i nezavisno jedna od druge. ak ta vie, svaka od ovih grupa e biti pozivane od potpuno razliitih dijelova aplikacija koji ih koriste. Zbog svega ovoga, dizajn koji je prikazan na slijedeoj slici je moda bolji. On odvaja dvije odgovornosti u dva nezavisna interfejsa. Ovakvo rjeenje, u najboljem sluaju, uva klijentsku aplikaciju od medjusobnog uticaja dvije razliite odgovornosti.

Slika 3: Interfejs modema sa odvojenim odgovornostima u nezavisnim klasama Ipak, uoite da je u dijagramu izvreno povezivanje ove dvije odgovornosti u jednu ModemImplementation klasu. To nije poeljno ali je ponekad ipak, i pored svega neophodno. Postoje razlozi koje moramo imati u vidu tokom dizajniranja sistema, koji se nalaze u hardverskoj implementaciji ureaja ili u operativnom sistemu koje moramo

prihvatiti kao takve i zbog kojih smo prinueni da naruimo SRP. Ovi i ovakvi razlozi nas ponekad primoravaju da poveemo klase koje inae u drugim okolnostima tako ne bi realizovali.

Zakljuak
SRP je jedan od najjednostavnijih principa i jedan od najteih da se postavi korektno. Uvezivanje i spajanje odgovornosti je neta to mi radimo prirodno u naoj svijesti. Ipak, pronalaenje i odvajanje jedne odgovornosti od druge odgovornosti je jedan od teinih zadataka u realizaciji dizajna softvera.