VELEUČILIŠTE U RIJECI

Ana Pulić
SINGLE RESPONSIBILITY PRINCIP
(seminarski rad)

Rijeka, 2018.
 VELEUČILIŠTE U RIJECI
Poslovni odjel
Specijalistički diplomski stručni studij informacijske tehnologije u poslovnim sustavima

SINGLE RESPONSIBILITY PRINCIP

(Seminarski rad)

Mentori: Student:
dr. sc. Ivan Pogarčić, profesor visoke škole Ana Pulić
Vlatka Davidović, predavač MBS: 2422000094/17

Rijeka, svibanj 2018.

SAŽETAK

Cilj ovog rada bio je napraviti istraživanje razloga primjene uzoraka dizajna u dizajnu i
izgradnji objektno orijentiranih aplikacija s posebnim osvrtom na princip jedne odgovornosti. U
prvom su djelu objašnjeni razlozi zbog kojih je došlo do potrebe uvođenja uzoraka i principa
softverskog dizajna, te njihove glavne prednosti. Drugi dio rada posvećen je principu jedne
odgovornosti, gdje je osim teorijskog objašnjenja prikazan i objašnjen praktični primjer kršenja i
poštivanja tj. implementacije principa jedne odgovornosti u C# programskom jeziku.

Ključne riječi: objekto orijentirano programiranje, uzorci, principi softverskog dizajna,

princip jedne odgovornosti
SADRŽAJ

1. Uvod..........................................................................................................................................1
2. Uzorci dizajna...........................................................................................................................2
2.1. Potrebe za definiranjem uzoraka dizajna...........................................................................2
2.2. Klasifikacija uzoraka dizajna.............................................................................................3
2.3. SOLID principi softverskog dizajna..................................................................................3
3. Princip jedne odgovornosti (Single Responsibility princip).....................................................4
4. Primjer primjene principa jedne odgovornosti..........................................................................6
4.1. Kršenje principa jedne odgovornosti.................................................................................6
4.2. Implementacija principa jedne odgovornosti.....................................................................9
5. Zaključak.................................................................................................................................13
 1. Uvod

Ranih devedesetih godina prošlog stoljeća objektno orijentirano programiranje razvilo se u

dominantnu granu paradigme programiranja, a programski jezici koji podržavaju tehnologije
opisane već ranijih godina postaju široko dostupni. Objektno orijentirani princip programiranja
definira razvoj sustava kroz tri osnovne faze, sukladno fazama živornog ciklusa razvoja softvera.
To su faze objektno orijentirane analize, objektno orijentiranog dizajna i objektno orijentirane
implementacije.

Faza objektno orijentiranog dizajna jedna je od najizazovnijih budući da predstavlja temelj za

pisanje budućeg programskog koda. Ona ukjlučuje grafički prikaz klasa UML dijagramima, te
detaljan opis njihovih svojstava (atributa) i metoda (operacija) kao i njihove međusobne
povezanosti. Izazovi objektno orijentiranog dizajna rješavaju se kroz nekoliko pristupa među
kojima je najpoznatiji pristup tzv. „design patterns“ (hrv. uzorci dizajna).

U poglavljima koja slijede dan je pregled osnovnih uzoraka dizajna i način njihove primjene
u objektno orijentiranom dizajnu, s posebnim naglaskom na princip jedne odgovornosti (eng.
Single Responsibility Principle, SRP) uz predstavljeni praktični primjer.

1
 2. Uzorci dizajna

2.1. Potrebe za definiranjem uzoraka dizajna

Promjene u procesu razvoja softvera nemogu se izbjeći. Novi zahtjevi korisnika budućeg
sustava zahtjevaju izmjenu postojećeg programskog koda, redizajn i novo testiranje. Razlozi za
izmjenu softvera su mnogobrojni, od potrebe za izmjenom postojećih funkcionalnosti, dodavanja
novih funkcionalnosti na korisnički zahtjev, pa sve do izmjene izgleda korisničkog sučelja,
načina povezivanja s drugim sustavima i sl. Problemi koji se u tom procesu javljaju donose nove,
neplanirane novčane i vremenske troškove za projektni tim koji softver razvija.
(https://moodle.srce.hr/2017-2018/pluginfile.php/1658927/mod_resource/content/1/uzorci
%20dizajna-2.dio.pdf)

Bez obzira na ograničenja softver se mora neprekidno prilagođavati unutarnjim ali i vanjskim
čimbenicima, kao što su promjena ili proširenje tržišta klijenta, izmjena zakonskih regulativa
(npr. zaštita osobnih podataka) i sl. Razvoj novog hardvera, dodavanje novih uređaja, migracija
podataka u baze podataka drugih proizvođača i prestanak tehničke podrške za povezane
softverske sustave samo su neki od brojnih razloga zašto bi se funkcionalna aplikacija trebala
mijenjati. Može se sa sigurnošću reći da promjene u okolini orgnizacije uzrokuju promjene u
softveru kojega ona koristi, a jednom izgrađen funkcionalan softver nikad ne ostaje isti.
(https://moodle.srce.hr/2017-2018/pluginfile.php/1658927/mod_resource/content/1/uzorci
%20dizajna-2.dio.pdf)

Da bi se prilagodio novim izazovima i bez većih poteškoća rješio navedene probleme,

softverski proizvod prije svega treba biti fleksibilan. To znači da programski kod treba biti pisan
tako da omogućuje jednostavno nadograđivanje i ponovno korištenje, čime se ujedno skraćuje
vrijeme isporuke i testiranja softverskog proizvoda. S druge strane, mijenjani podsustav ne bi
smio utjecati na funkcioniranje ostalih podsustava softvera koji se razvija.
(https://moodle.srce.hr/2017-2018/pluginfile.php/1658927/mod_resource/content/1/uzorci
%20dizajna-2.dio.pdf)

2
 2.2. Klasifikacija uzoraka dizajna

Uzimajući u obzir sve navedeno dolazi se do zaključka da bi se prilikom izrade softvera

trebalo težiti takvom dizajnu da se on može jednostavno održavati, lako mijenjati i ponovno
koristiti bez neočekivanih ispada. (https://moodle.srce.hr/2017-
2018/pluginfile.php/1658927/mod_resource/content/1/uzorci%20dizajna-2.dio.pdf)

Stoga su 1994. Erich Gamma, Richard Helm, Ralph Johnson i John Vlissides predstavili
knjigu naslova “Design Patterns: Elements of Reusable Object-Oriented Software“ kojom su
definirali 23 principa dobrog dizajna u objektno orijentiranom programiranju. Prema navedenom
izvoru uzorci dizajna predstavljaju testirana i pouzdana rješenja problema koji se mogu javiti u
objektno orijentiranom dizajnu. Međutim oni nisu i gotova rješenja koja se mogu odmah samo
primjeniti. Za njihovu upotrebu potrebno je ispravno identificirati koji uzorak (ili više njih)
koristiti, što je najzahtjevniji dio posla.
(https://bib.irb.hr/datoteka/358252.Konecki_Stapic_Orehovacki.pdf)

Prema navedenom izvoru (Design Patterns: Elements of Reusable Object-Oriented Software)

uzorci dizajna kategorizirani su u tri skupine prema funkciji, kako bi se potrebni uzorak lakše
identificirao i pronašao (https://bib.irb.hr/datoteka/358252.Konecki_Stapic_Orehovacki.pdf):

 Uzorci kreiranja – uzorci koji se bave mehanizmima stvaranja objekata, tako što
stvaraju objekte na način prikladan za trenutnu situaciju
 Uzorci strukture – uzorci koji omogućavaju jednostavnu realizaciju veza između
entiteta
 Uzorci ponašanja – uzorci koji pomažu u realizaciji komunikacije između objekata

2.3. SOLID principi softverskog dizajna

U objektno orijentiranom dizajnu programer bi trebao obratiti pozornost na dobru praksu

pisanja programskog koda. Karakteristike lošeg softverskog dizajna koje bi trebalo izbjeći jesu
rigidnost (softver je teško mijenjati), lomljivost (neočekivani ispadi u softveru nakon izmjene) i
nepokretnost (softver nije moguće ponovno koristiti). Kako bi se izbjegle navedene karakteristike

3
programskog koda, svi uzorci dizajna sljede principe dobrog dizajna, koji su općenitiji i
primjenjivi na svaki softverski proizvod. (https://moodle.srce.hr/2017-
2018/pluginfile.php/1658927/mod_resource/content/1/uzorci%20dizajna-2.dio.pdf)

Američki softverski inženjer Robert C. Martin, u svojoj knjizi „Agile Software Development:
Principles, Patterns, and Practices“, definira i opisuje pet osnovnih principa suvremenog
softverskog dizajna. To su: (https://moodle.srce.hr/2017-
2018/pluginfile.php/1658927/mod_resource/content/1/uzorci%20dizajna-2.dio.pdf)

 Princip jedne odgovornosti (eng. Single responsibility principle) – klasa bi trebala

imati samo jedan razlog za promjenu
 Otvoreno-zatvoreni princip (eng. Open-closed principle) – softverski moduli trebali bi
biti otvoreni za proširivanje, a zatvoreni za promjene
 Princip Liskove supstitucije (eng. Liskov substitution principle) – objekti naslijeđenih
tipova trebali bi moći zamjeniti objekte osnovnih tipova bez promjene ponašanja
 Princip izdvajanja sučelja (eng. Interface segregation principle) – klase ne bi trebale
ovisiti o sučeljima koja ne koriste
 Princip inverzne ovisnosti (eng. Dependency inversion) – komponente na višem nivou
ne bi trebale ovisiti o komponentama na nižem nivou, a jedne i druge bi trebale ovisiti
o apstrakcijama, a ne o konkretnim klasama

U narednim poglavljima definiran je i opisan princip jedne odgovornosti, te je prikazan

praktični primjer korištenja navedenog uzorka.

3. Princip jedne odgovornosti (Single Responsibility princip)

Princip jedne odgovornosti (eng. Single Responsibility Principle) je ključni princip

softverskog dizajna koji određuje način na koji bi programer trebao modularizirati programski
kod u objektno orijentiranom programiranju.

Princip jedne odgovornosti nalaže kako bi klasa (ili bilo koji drugi modul programskog koda,
npr. metoda) trebala imati samo jednu odgovornost. Robert C. Martin definira pojam
„odgovornost“ kao razlog za promjenu i zaključuje kako bi klasa trebala imati „jedan i samo

4
jedan razlog za promjenu“. (https://hackernoon.com/you-dont-understand-the-single-
responsibility-principle-abfdd005b137)

Kao primjer, možemo razmotriti modul koji sastavlja i ispisuje izvješće. Takav modul može
se promjeniti iz različitih razloga, primjerice zasigurno će se mjenjati sadržaj izvješća, a može se
dogoditi i da se izmjeni format ispisa. Princip jedne odgovornosti kaže da su ta dva problema
zapravo dvije zasebne odgovornosti, te zbog se zbog toga trebaju razdvojiti u zasebne module.
(https://hackernoon.com/you-dont-understand-the-single-responsibility-principle-abfdd005b137)

Slika 1. – Apstraktni primjer kršenja principa jedne odgovornosti u stvarnom životu

Izvor: https://www.c-sharpcorner.com/UploadFile/pranayamr/what-is-single-responsibility-
principle/

Može se zaključiti kako je suština principa jedne odgovornosti zapravo kohezija – klasa mora
biti kohezivna. Ako postoji klasa koja ima više od jednog razloga za promjenu, onda ima i više
odgovornosti. Taj problem rješava se odvajanjem različitih odgovornosti u različite klase. Kako
bi se utvrdilo da klasa uistinu ima više odgovornosti promatra se mogućnost promjene te klase
kroz neki period, te je dobra praksa odvojiti onaj dio programskog koda za kojeg postoji
mogućnost da se promjeni, od dijela klase koji se zasigurno neće mijenjati. Uobičajeno je da se iz
klasa koje sadrže stalne atribute i metode (npr. metode setteri i metode getteri) odvoje poslovna
pravila koja se iz raznih razloga često znaju mijenjati. (https://moodle.srce.hr/2017-
2018/pluginfile.php/1658927/mod_resource/content/1/uzorci%20dizajna-2.dio.pdf)

5
 Problem koji se u objektno orijentiranom programiranju javlja kod kršenja principa jedne
odgovornosti je uvođenje nove klase u programski kod koja treba implementirati samo neke od
postojećih karakteristika (metoda) postojeće klase. U slučaju kada se odgovornosti ne bi odvojile,
nova klasa trebala bi implementirati sve odgovornosti čime postaje ovisna o karakteristikama
koje se mijenjaju što može uzrokovati probleme u programskom kodu i povećati mogućnost
neočekivanih ispada i vezanih grešaka u programu. Zato se odvajanjem odgovornosti osigurava
fleksibilnost programskog koda, što znači da programer može dodavati nove klase u postojeći
programski kod, te u njih implementirati samo one funkcionalnosti koje im odgovaraju tj. Koje su
im potrebne. (https://moodle.srce.hr/2017-
2018/pluginfile.php/1658927/mod_resource/content/1/uzorci%20dizajna-2.dio.pdf)

4. Primjer primjene principa jedne odgovornosti

Za primjer primjene principa jedne odgovornosti, uz ovaj rad kreirana je i konzolarna

aplikacija koja od korisnika traži unos njegovog imena i prezimena. Aplikacija potom validira
unesene podatke (provjerava da li je unesen skup nekih znakova ili je polje za unos prazno), te
generira korisničko ime za tog korisnika. Aplikacija je pisana u C# programskom jeziku u Visual
Studiu 2015.

4.1. Kršenje principa jedne odgovornosti

U Visual Studiu kreiran je novi projekt – C# konzolarna aplikacija. U projekt je dodana klasa
modela naziva Korisnik koja sadrži dva parametra – ime i prezime, te metode set i get za svaki
parametar. (Slika 2.)

Slika 2. – Klasa Korisnik

6
 Izvor: obrada autora

Glavnu klasu s izvršnom metodom Visual Studio generira sam prilikom kreiranja novog
projekta dajući joj naziv Program. U izvršnoj metodi prilikom pokretanja aplikacije ispisuje se
tekst „Dobrodošli u aplikaciju za generiranje korisničkog imena!“, te se od korisnika zatraži
unos njegovog imena i prezimena. Korisnikov unos sprema se u objekt klase Korisnik koji je
prethodno kreiran sljedećom naredbom:

Korisnik korisnik = new Korisnik();

Aplikacija potom validira korisnikov unos, tj kroz if grananje provjerava se da li je korisnik

unio neki skup znakova ili je ostavio prazan unos. Ukoliko je unos prazan od korisnika se traži da
unese tražene podatke. Nakon uspješne validacije imena i prezimena aplikacija generira za
korisnika njegovo korisničko ime po definiranoj formuli uzimajući prvo slovo unesenog imena i
spajajući ga na uneseno prezime. Klasa Program prikazana je na slici 3.

Slika 3. – Klasa Program

7
 Izvor: obrada autora

Postoje mnogobrojni razlozi zašto bi se klasa Program u budućnosti mogla mjenjati. Neki
od najočitijih razloga su:

 Mjenjanje konzolarnog ispisa (izmjena pozdravne poruke na početku, dodavanje

pozdravne poruke na kraju, izmjena poruka kojim se od korisnika traži unos njegovih
podataka)
 Izmjena načina dohvaćanja korisnikovog unosa
 Izmjena načina na koji se validira korisnikov unos
 Izmjena formule po kojoj se generira korisničko ime
 Dodavanje mogućnosti generiranja lozinke

8
 Gledajući s aspekta softverskog dizajna, svaka od navedenih točaka predstavlja jedan
razlog za promjenu tj. jednu odgovornost. Budući da princip jedne odgovornosti nalaže kako
klasa mora imati samo jednu odgovornost, može se zaključiti da ovako napisan programski kod,
iako ispravan i funkcionalan, krši princip jedne odgovornosti.

4.2. Implementacija principa jedne odgovornosti

Čak i bez uvođenja prethodno navedenih promjena u kreiranu konzolarnu apliakciju klasa
Program ima više zadaća, odnosno više odgovornosti:

 Ispisivanje standardnih poruka korisniku

 Dohvaćanje korisničkog unosa
 Validacija unesenih podataka
 Generiranje korisničkog imena

Budući da je klasa Program glavna klasa s izvršnom metodom, jedina njezina

odgovornost trebala bi biti praćenje tijeka aplikacije, što u prethodno prikazanom primjeru nije
slučaj. Kako bi se zadovoljio princip jedne odgovornosti rješenje je svaku od navedenih
odgovornosti odvojiti u zasebne klase.

Nova klasa Poruka ima zadaću ispisivanja standardnih poruka na korisnikovu konzolu.
To su poruka dobrodošlice koja se ispisuje u metodi pozeliDobrodoslicu, završetak
programa tj. izlaz iz aplikacije koji se događa u metodi zavrsi i poruka koja se korisniku prikaže u
metodi prikaziValidacijskuGresku ukoliko validacija nije prošla, odnosno ukoliko
korisnik nije unio ime ili prezime. (Slika 4.)

Slika 4. – Klasa Poruka

9
 Izvor: obrada autora

Klasa UnosPodataka zadužena je za onaj dio aplikacije koji od korisnik traži i

dohvaća njegovo ime i prezime. Korisnikov unos dohvaća se kroz metodu dohvatiPodatke
koja vraća objekt tipa Korisnik. (Slika 5.)

Slika 5. – Klasa UnosPodataka

Izvor: obrada autora

Novoj klasi Validator dan je zadatak validiranja podataka koje je korisnik unio. Kroz
metodu validiraj provjerava se da li je korisnikovo ime i prezime prazan string. Ako je (u
onom slučaju kada korisnik nije unio ime ili prezime) poziva se metoda

10
prikaziValidacijskuGresku iz klase Poruka. Ukoliko je validacija prošla ispravno
metoda vraća vrijednost true. (Slika 6.)

Slika 6. – Klasa Validator

Izvor: obrada autora

Zadnji dio aplikacije je generiranje korisničkog imena za korisnika na temelju unesenih

podataka. Taj posao obavlja klasa Generator kroz metodu generirajRacun. (Slika 7.)

Slika 7. – Klasa Generator

Izvor: obrada autora

Nakon implementacije principa jedne odgovornosti glavna klasa ima samo jedan zadatak,
a to je praćenje tijeka programa. (Slika 8.)

11
 Slika 8. – Klasa Program nakon implementacije principa jedne odgovornosti

Izvor: obrada autora

5. Zaključak

12
 U procesu dizajna i izrade objektno orijentiranih aplikacija posebnu pažnju treba posvetiti
činjenici da niti jedan programski proizvod ne ostaje istim kao u trenutku isporuke krajnjem
korisniku. Promjene u softveru su neminovne, a osobito u slučajevima kada se neki softver
razvija u poslovne svrhe. Postoji mnogo razloga zašto bi neka aplikacija trebala promjenu, od
korisničkih zahtjeva, dodavanja novih funkcionalnosti, izmjene poslovnih pravila pa sve do
zakonski promjena i uvođenja novih regulativa. Stoga, kao bi softver bio jednostavan za
održavanja, neophodno je voditi se uzorcima i principima softverskog dizajna. Jedan od
značajnijih principa, opisan u ovom radu, je princip jedne odgovornosti koji nalaže da bi klasa (ili
bilo koji drugi programski modul) trebala imati samo jedan razlog za promjenu. Odvajanjem
odgovornosti u zasebne klase postiže se ne samo razumijevanje programskog koda od strane
drugih programera, već i jednostavnost u uvođenju promjena i lakše održavanje softverskog
proizvoda.

13
Literatura

1. C# Corner, „What is Single Responsibility Principle?“ (https://www.c-

sharpcorner.com/UploadFile/pranayamr/what-is-single-responsibility-principle/,
10.5.2018.)
2. Hackernoon, „Think you understand the Single Responsibility Principle?“
(https://hackernoon.com/you-dont-understand-the-single-responsibility-principle-
abfdd005b137, 10.5.2018.)
3. Konecki, M., Stapić, Z., Orehovački, T., „Razvoj aplikacija korištenjem uzoraka dizajna“
(https://bib.irb.hr/datoteka/358252.Konecki_Stapic_Orehovacki.pdf, 10.5.2018.)
4. Skripta sa vježbi iz kolegija „Izgradnja objektno orijentiranih aplikacija“
(https://moodle.srce.hr/2017-2018/pluginfile.php/1658927/mod_resource/content/1/uzorci
%20dizajna-2.dio.pdf, 10.5.2018.)

14
 Popis slika

Slika 1. – Apstraktni primjer kršenja principa jedne odgovornosti u stvarnom životu....................5

Slika 2. – Klasa Korisnik.............................................................................................................7
Slika 3. – Klasa Program..................................................................................................................8
Slika 4. – Klasa Poruka...............................................................................................................10
Slika 5. – Klasa UnosPodataka.................................................................................................10
Slika 6. – Klasa Validator...............................................................................................................11
Slika 7. – Klasa Generator..............................................................................................................11
Slika 8. – Klasa Program nakon implementacije principa jedne odgovornosti...........................12

15