Dizajn šema

**Dizajn šema** (en. *design pattern*) u računarskom inžinjeringu je stalno ponavljano riješenje učestalom problemu u softverskom dizajnu. U principu, ovo nije krajnje riješenje koje se može direktno pretvoriti u izvorni kod, nego je više opis ili šablon po kojem se problem može riješiti u raznim situacijama. Objektno orijentirane dizajn šeme obično pokazuju odnos između raznih klasa ili objekata, bez detaljnog opisa tih klasa ili objekata. Algoritmi se ne smatraju dizajn šemama jer oni riješavaju probleme u zadatcima, a ne probleme dizajna.

## Historija
Dizajn šeme su započele život u arhitekturi, čiji je tvorac Christopher Alexander, arhitekta i akademik. U 1987. Kent Beck i Ward Cunningham su počeli eksperimentirati sa upotrebom šema u računarstvu, te su izjasnili svoje rezultate na OOPSLA konferenciji iste godine.

Širu popularnost u računarstvu, dizajn šeme dobijaju nakon izlaska knjige ''Design Patterns: Elements of Reusable Object-Oriented Software''  1994. Iste godine se održava prva konferencija o PLoPu, te nardne godine se uspostavlja Portland Pattern Repository koji ima cilj da dokumentira dizajn šeme. Obim ovog izraza je promlematičan u narednoj deceniji.

## Upotreba
Dizajn šeme mogu ubrzati razvoj softvera tako što daju isprobane i testirane programske paradigme. Uspješan softverski dizajn zahtijeva razmatranje problema koji se pojavljuju tek u kasnijim fazama razvoja. Ponovno korištenje postojećih šema pomaže kod izbjegavanja sitnih problema koji mogu izazvati daleko veće, te poboljšava čitkost programerima i arhitektama upoznatim za šemom.

Često softver inžinjeri znaju da primjene samo neke od metoda dizajna u svom softverskom rješenju. Međutim te metode znaju biti problematične kad se primjenjuju pri rješavanju šireg spektra problema. Dizajn šeme nude uopštena rješenja koja su dokumentirana na način koji ne zahtijeva da se prave (implementiraju) na određeni način.

Dizajn šeme se sastoje od više dijelova (pogledajte Dokumentaciju), mada od naročitog interesa su struktura, list učesnika i saradnja. Ovi dijelovi opisuju *dizajn motiv*, tj. (proto)tipična *mikro-arhitektura* koju programeri kopiraju i adaptiraju svojim potrebama da riješe stalno ponovljivi problem opisan u dizajn šemi. Programeri koriste dizajn šemu tako što u svojim programima koriste ove (proto)tipičnu mikro-arhitekturu, što znači da mikro-arhitektura u njihovom dizajnu ima sličnu strukturu i organizaciju odabranom dizajn motivu.

Koristeći dizajn šeme, programeri su u stanju da komuniciraju koristeći dobropoznate, veoma razumljive pojmove za razvoj softvera. Ti uopšteni principi, tj. dizajn šeme se mogu poboljšati s vremenom, što nije moguće ako sa *spontanim* ( en. *ad-hoc* ) dizajnom.

## Podjela
Dizajn šeme mogu biti razvrstane u okviru raznih kriterija, međutim najčešće se dijele na osnovu problema koje rješavaju. Po ovoj kriteriji, šeme su podjeljene na:
* Osnovne šeme
* Šeme stvaranja
* Šeme strukture
* Šeme ponašanja
* Istovremene šeme
* Arhitektonske šeme

## Dokumentacija
Dokumentacija dizajn šeme treba da sadrži dovoljno podataka o problemu koji treba rješiti, kontekst (okvir) upotrebe, te predloženo rješenje. Mada autori obično koriste svoj format dokumenata, njiho format sadrži napomenute podatke. Često se uključe dodatni podatci koji daju detaljniji opis i organiziraju elemente šeme u različitim dijelovima, obično sa različitim imenima.

Uobičajeni format je opisan u gorespomenutoj knjizi ''Četvorice Otpisanih'' () i sadrži sljedeće dijelove:
* **Ime i podjelu šeme** - svaka šema treba da ima jedinstveno i opisivo ime, pomoću kojeg se ona može prepoznati. Povrh toga, treba se klasificirati po podjeli, poput gorespomenute podjele, pošto ta podjela olakšava prepoznavanje kada se ta šema treba koristiti.
* **Namjeru** - ovaj dio treba da opiše cilj šeme i razloge za upotrebu, tj. ovo je opis problema šeme.
* **Također poznata kao** - ako je šema poznata pod drugim nazivima, onda se ti nazivi navode u ovom dijelu.
* **Razlog** - ovaj dio sadrži scenario napravljen od opisa problema i konteksta unutar kojeg se šema može koristiti. Pošto povezuje problem i kontekst, ovaj dio dokument također razjašnjava kad treba koristiti šemu.
* **Primjena** - u ovom dijelu se opisuje situacije u kojima treba primjeniti šemu, tj. opisuje kontekst šeme.
* **Struktura** - grafička slika šeme, obično nacrtana koristeći UML-ov diagram klasa ili diagram redoslijeda.
* **Lista učesnika** - je lista klasa i objekata korištenih u šemi i njihove uloge.
* **Suradnja** - opisuje kako klase i objekti surađuju u šemi.
* **Konsekvence** - ovaj dio opisuje rezultate, nepoželjne efekte i čega se mora odreći pri primjeni šeme.
* **Implementacija** - ovaj dio opisuje rješenje i način primjene šeme. Detaljniji tehnički detalji i predlozi oko implementacije se također navode u ovom dijelu.
* **Primjer [[Izvorni kod|izvornog koda]]** - ilustracija kako se ova šema može napisati u nekom od programskih jezika.
* **Poznate upotrebe** - u ovom dijelu se navode upotrebe ove šeme u stvarnom životu.
* **Vezane šeme** - dio sadrži listu šema koje su vezane za šemu, koje se mogu koristiti zajedno sa ovom šemom ili umjesto ove šeme. Također se navode razlike između šeme i vezanih šema.

## Kritika
Koncept dizajn šeme je pod udarom kritike od strane nekih u polju računarstva, najviše iz sljedećih razloga:

### Nezadovoljavajuća abstrakcija dizajn šema
Neki od kritičara misle da potreba za šemama je rezultat korištenja programskih jezika ili metoda sa nezadovoljavajućim nivoom abstrakcije. Idealna faktorizacija zahtijeva da se koncept ne kopira, nego da se samo *referncira*. Međutim, ako je nešto referencirano a ne kopirano, onda tu nema *šeme* koja sa može označiti i katalogovati.

Čak i gore navedena knjiga, *Design Patterns: Elements of Reusable Object-Oriented Software* , je često pod udarom kritike poput izjave da od navedenih 23 šema (opisanih u C++-u) čak 16 je eliminisano ili pojednostavljeno u jezicima poput Lispa ili Dylan-a.

### Teorijska potpora dizajn šema
Neki teoretičari tvrde da su studiji dizajn šema previše spontani () te da njihovom konceptu neophodna formalizacija.

## Napomene