Vladimir Milovanović

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.

Š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.

    //mojaKlasa.cs
    public partial class mojaKlasa
    {
        public mojaKlasa()
        {

        }
    }
    
    //mojaKlasa.Logika.cs
    partial class mojaKlasa
    {

    } 

 <ItemGroup>
...
    <Compile Include="mojaKlasa.cs">
      <SubType>mojaKlasa</SubType>
    </Compile>
    <Compile Include="mojaKlasa.Logika.cs" >
      <DependentUpon>mojaKlasa.cs</DependentUpon>
      <SubType>mojaKlasa</SubType>
    </Compile>
...