Mikro arhitektura – GoF uzori

GoF(Gang of Four) uzori su se prvi put pojavili u knjizi „Design Patterns – Elements of Reusable Object-Oriented software“ koju su napisali Erich Gamma, Richard Helm, Ralph Johnson i John Vlissides. Oni su u toj knjizi predstavili neke od najčešće korišćenih uzora i klasifikovali ih prema nameni na uzore kreiranja, strukture i ponašanja i prema domenu na uzore klasa i objekata. Postoje i drugi načini da se klasifikuju uzori. Neki uzori se često koriste zajedno. Na primer, sastavnica(composite) se često koristi uz Iterator ili Posetioca(Visitor). Neki uzori su alternative: Prototip je često alternativa apstraktnoj fabrici, kao i builder.

Uzori kreiranja

Uzori kreiranja apstrahuju proces instanciranja. Pomoću njih sistem postaje nezavisan od načina pravljenja, sastavljanja i predstavljanja objekata. Uzor za pavljenje sa domenom klase koristi nasleđivanje za menjanje klase koja se instancira, dok uzori za pravljenje sa domenom objekta delegira instanciranje nekom drugom objektu.

Uzori kreiranja postaju važni kada sistemi dođu u fazu da više zavise od sastavljanja objekata nego od nasleđivanja. U takvoj situaciji, naglasak sa fiksnog kodiranja fiksnog skupa ponašanja prelazi na definisanje manjeg skupa osnovnih ponašanja koja se mogu sastavljati u veći broj složenijih. Prema tome, pravljenje objekata sa nekim određenim ponašanjem zahteva više od pukog instanciranja klase.

Kod ovih uzora postoje dve teme koje se stalno ponavljaju. Prvo, svi uzori enkapsuliraju znanje o tome koje konkretne klase sistem koristi. Drugo, oni kriju kako se prave konkretni objekti ovih klasa i kako se sastavljaju. U celom sistemu se o objektima zna jedino za njihove interfejse, na osnovu toga kako su definisani u apstraktnim klasama.

Uzori strukture

Strukturni uzori se bave načinom na koji se klase i objekti sastavljaju u veće strukture. Strukturni uzori klasa koriste nasleđivanje za sastavljanje interfejsa ili implementacija. Strukturni uzori sa domenom objekata opisuju načine za postizanje nove funkcionalnosti kombinovanjem objekata umesto sastavljanjem interfejsa ili implementacija. Dodatna fleksibilnost sastavljanja objekata potiče od mogućnosti da se sastav menja u vreme izvršavanja, što je nemoguće kod statičkog sastavljanja klasa.

Uzori ponašanja

Uzori ponašanja se bave algoritmima i raspodelom odgovornosti među objektima. Uzori ponašanja ne opisuju samo uzore objekata ili klasa, već i uzore njihove međusobne komunikacije. Ovi uzori opisuju prirodu složenog toka kontrole koji se teško prati u vreme izvršavanja. Pažnja prelazi sa samoga toka kontrole na način međusobnog povezivanja objekata.

Klasni uzori ponašanja koriste nasleđivanje za distribuiranje ponašanja među klasama. Objektni uzori ponašanja koriste sastavljanje objekata, a ne nasleđivanje. Neki od njih opisuju kako grupa objekata ortaka sarađuje na zadatku koji nijedan od njih ne može sam da obavi. Ovde je važno kako ti objekti saznaju jedan za drugoga. Oni bi mogli da čuvaju međusobne eksplicitne reference, ali bi to pojačalo njihovo vezivanje. U krajnjem slučaju bi svaki objekat znao za sve ostale.

Kod svih GoF uzora se može primetiti struktura koja se sastoji od klijenta, apstraktnog servera i konkretnih servera. To se može prikazati sledećim UML dijagramom.

Arhitekturni uzori i MVC

Pre nego što počnem o ovome, mislim da treba da razgraničimo šta su nivoi a šta slojevi.
Sloj (En. Layer)
Nivo (En. Tier)
Koja je razlika između ova dva? Iako na prvi pogled deluju kao sinonimi, razlika je ogromna. Kada se govori o slojevima, prvo se misli na logičkom nivou, dok se kod nivoa misli na fizičkom. Šta to znači u programiranju? S obzirom da ću se koncentrisati na .NET framework, koristiću termine koji su tamo standardni, ali verujem da će se i poklonici ostalih jezika snaći. Ako kažemo da imamo dve klase koje pripadaju različitim slojevima, to znači da su one u istom projektu, ali u okviru različitih namespace-ova. Dok ako kažemo da dve klase pripadaju različitim nivoima, to znači da pripadaju različitim projektima, pa čak i da su na različitim računarima nakon instalacije.

Uzori arhitekture izražavaju fundamentalnu strukturnu organizaciju ili šemu sistema. Oni pružaju set predefinisanih podsistema, opisuju njihove odgovornosti i uključuju pravila i smernice za organizaciju odnosa između datih podsistema. Ono što je bitno kod arhitekturnih uzora, to je da oni nisu previše konkretni. Oni predstavljaju jednu ogromnu apstrakciju sistema, koja se može tumačiti i implementirati na više načina.

Postoji više uzora arhitekture. MVC je samo jedan od njih. IBM je skupio neke ahtitekturne uzore koji se odnose na e-poslovanje. Možete ih pogledati ovde: http://www-128.ibm.com/developerworks/patterns/
Ako želite da saznate više o arhitekturnim uzorima pogledajte http://wi.wu-wien.ac.at/home/uzdun/publications/ArchPatterns.pdf i http://en.wikipedia.org/wiki/Architectural_pattern_(computer_science) , a ja ću se zadržati MVC uzoru

MVC (Model – View – Controller) uzor je arhitekturni uzor koji organizuje aplikaciju u tri odvojena sloja: jedan za aplikacioni model sa prikazom podataka i biznis logikom, drugi za prezentaciju podatala korisniku i unos podataka i treći za kontroler koji prosleđuje zahteve i izvršava tok. Imajte na umu da arhitekturni uzori uzimaju olako termine kao što su sloj i nivo, jer im je svejedno da li će se MVC na primer implementirati u okviru jednog projekta ili više.

Postoji više implementacija MVC uzora, ali dva najčešća imaju oblike kao na slikama

Pune linije predstavljaju direktne asocijacije, dok su isprekidane indirektne. Isprekidane linije se mogu implementirati preko događaja, ali je najpoželjnije da se implementira preko observer uzora, o kome ću malo kasnije kada budem pisao o GoF uzorima.

Šta radi Kontroler:
Upravlja tokom programa
Odlučuje koji view da prikaže
Odlučuje koji model da menja
Upravlja izuzecima

Šta radi View:
Renderuje UI (HTML, GUI…)
Omogućava prikaz korisnicima
Prihvata i proverava da li su podaci validni

Šta radi model:
Sadrži poslovnu logiku
Ima pristup nižim servisima
Sadrži perzistentne objekte (iako je model sam po sebi tranzijentan)

Uzori u projektovanju programa – uvod

Šta je zapravo softverska arhitektura? Odgovor na to pitanje se nalazi na više nivoa. Na najvišem nivou, nalaze se arhitekturni uzori koji definišu sveukupan oblik i strukturu aplikacije. Na nižem nivou je arhitektura koja je specifična za aplikaciju koju razvijamo. Na još nižem niovu je arhitektura modula, klasa i njihovih veza. To je zapravo nivo mikro arhitekture. Dok se na još nižem nivou nalaze idiomi.

Značaj uzora u proizvodnji složenih sistema je odavno priznat u drugim disciplinama. Konkretno, Kristofer Aleksander i njegove kolege su prvi predložili da se jezik uzora upotrebi u arhitekturi zgrada i gradova. Njegove ideje i doprinosi sada su ukorenjeni u zajednici objektno orijentisanog softvera.
Sve dobro strukturirane objektno orijentisane arhitekture su pune uzora. Ako se prilikom razvoja sistema usresredi na pravilno korišćenje uzora dobija se manja, jednostavnija i razumljivija arhitektura nego ako se ignorišu.

Uzori sadrže rešenja koja su se vremenom razvijala i proširivala. To nisu rešenja koja se prave iz prve, već su prošla dosta iterativnih poboljšanja.
Postoji više definicija šta je uzor. Najjednostavnija je „uzor je provereno rešenje za problem u datom kontekstu“. Međutim, mnogi smatraju da je ovo isuviše pojednostavljeno. Čak je i Richard Gabriel rekao „Alexander je mogao da napiše definiciju uzora u jednoj rečenici, ili esej, ali je umesto toga napisao knjigu od 550 stranica, zato što je koncept težak za razumevanje“.

Ovo je samo mali uvod u ono o čemu planiram da pišem. Stoga se može smatrati kao prvi od više članaka na tu temu.