Abstraktus Fabrikas

1. Abstraktus Fabrikas Abstract Factory (Creational)

2. Paskirtis • Abstract Factory šablonas aprašo interfeisą, leidžiantį kurti tarpusavyje susijusių grupių objektus, kūrimo metu nenurodant konkrečių kuriamų objektų klasių. • Provide an interface for creating families of dependent objects without specifying their concrete classes.

3. Motyvacija • Dažnai taikymo metu tenka pakeisti visus vienų klasių grupės egzempliorius kitais. • Grafinės vartotojo sąsajos išvaizdą Motif pakeisti Windows. • Jei naudosime sąlygos operatorius, gautume painų ir neaiškų kodą. • Jei bandytume papildyti taikymo galimybes nauja klasių grupe, reikėtų peržiūrėti ir taisyti visą sąlygos operatorių logiką. • Kodas taptų praktiškai neplečiamas.

4. Motyvacija • Abstract Factory šablonas abstrahuoja tarpusavyje susijusių klasių grupių kūrimo procesą. • Klientas nekuria konkrečių, iš anksto nustatytų objektų. Tik nurodo, kokią savybę turi turėti pageidaujami objektai. • Šablonas atskiria kliento kodą nuo jo naudojamų klasių egzempliorių kūrimo proceso (nesusieja kodų statiškai). • Įgalina vienu veiksmu pakeisti vieną naudojamų objektų grupę kita. • Leidžia neatskleisti klientui jo naudojamų klasių turinio.

5. Loginis modelis

6. Struktūra

7. Sekų diagrama

8. Struktūra • Šabloną sudaro fabrikų hierarchija prasidedanti abstrakčiąja klase arba interfeisu AbstractFactory ir produktų hierarchijos, prasidedančios abstrakčiosiomis klasėmis arba interfeisais AbstractProduct. • Fabrikų hierarchija skirta produktų hierarchijos egzemplioriams kurti. • Fabrikų hierarchijos egzemplioriai vadinami konkrečiais fabrikais (ConcreteFactory), produktų – konkrečiais produktais (ConcreteProduct). • Abstrakti klasė AbstractFactory pateika abstrakčių produktų kūrimo metodų createProduct antraštes. • Konkretiems produktams kurti skirtos klasės ConcreteFactory, kurios turi šių kūrimo metodų turinius.

9. Struktūra • Kiekviena Produktų hierarchija yra skirta vienai tam tikros rūšies objektų grupei: • Visų galimų taikymo išvaizdų (Motif ar Windows) mygtukams; • Visų galimų taikymo išvaizdų žymėms ir t.t. • Priskyrę AbstractFactory nuorodą pasirinktam konkrečiam Fabrikui, parenkame, kokius kiekvienos grupės objektus kursime. • Norint pridėti naują produktą, visų fabrikų interfeisai turės keistis.

10. Privalumai • Izoliuoja konkrečias klases nuo kliento. • AbstractFactory skirtas kontroliuoti kliento kuriamų objektų klases. • Produktų vardai izoliuoti ConcreteFactory realizacijoje, klientai naudoja atskirus atvejus per abstrakčius interfeisus. • Lengva keisti produktų šeimas. • Nesikeičia kliento kodas, kadangi nesikeičia abstraktūs interfeisai. • Kadangi Abstract Factory sukuria pilną produktų šeimą, visa produktų šeima keičiasi, kuomet keičiasi konkretus fabrikas. • Priseda prie objektų neprieštaringumo. • Konkretūs fabrikai užtikrina, kad tinkami produktai būtų naudojami kartu. • Išaugęs sistemos plečiamumas: • Galima kurti naujas komponentų grupes ir integruoti jas į sistemą, nekeičiant kitų sistemos komponentų.

11. Minusai • Sudėtingesniais atvejais gana sunku pasirinkti, kurios dažnai labai įvairių objektų savybės turi būti abstrahuojamos. • Sunku pridėti naujas produktų rūšis prie egzistuojančio fabriko. • Naujo produkto pridėjimas reikalauja praplėsti abstraktų interfeisą, kas reiškia, kad visos išvestinės klasės taip pat turi keistis. • Kad būtų palaikomos ir naudojamos naujos produktų šeimos, iš esmės viskas turi keistis: • Abstraktaus fabriko interfeisas yra praplečiamas; • Išvestiniai konkretūs fabrikai turi realizuoti praplėtimus; • Pridedama nauja abstraktaus produkto klasė; • Pridedama naujo produkto realizacija; • Turi būti praplėstas klientas, kad galėtu naudoti naują produktą.

12. Pavyzdys • Labiausiau reikalingas, kuomet grupė produktų, naudojama kliento kodo, yra labai priklausomi nuo suderinamumo tarpusavyje (family dependant products). • Turime šeimą: • Tėvas žmona dukra Šeimyninė Sportinė mašina Ekonominė

13. Pavyzdys • Abstract factory is a bit like asking a car-dealer for recommendations on the car to get for each of the members of your family based on two requirements: • In any given year, you all want to drive the same brand of car. • The particular type of car needed for each member of your family.

14. Pavyzdys • Susiesime klases, dalyvaujančias šablone ("Family-of-Products", "Abstract-Factory", "Concrete-Factory", "Abstract-Products" and "Concrete-Products"), su aktoriais mašinų pirkimo scenarijuje. • “Family of products" – visi produktai, kurie dirba kartu. • Honda-Accord, Honda-Civic, Honda-Prelude - viena šeima. • Toyota-Camry, Toyota-Corolla, Toyota-Celica – kita šiema

15. Klasių diagrama

16. Pavyzdys • Abstract product – mašinos tipas, pvz. ekonominė. • Valdo konkrečių produktų (concrete products) elgesį. Abstract product ekonominė šeimyninė sportinė Civic Corolla Prelude Celica Accord Camry Concrete products

17. Pavyzdys • Abstract Factory – atstovaujamas mašinų gamintojų arba valstybinių agentūrų, kurios reguliuoja mašinų pirkimą. Šiuo atveju jos užtikrina, kad visi prekiautojai mašinomis aprūpintų trimis mašinų tipais. • Jei prašom ekonominės, tai ir gausim ekonominę, o ne kokią nors kitokią. • Nissan, Honda ir Toyota atvaizduoja konkretų fabriką (concrete factory) šablone. • Concrete factory reiškia aktorių, kuris yra atsakingas už produkto prieinamumą klientui.

18. Pavyzdys • Clientas – šiuo atveju pirkėjas. Jo žinios apie mašinas apsiriboja dviem aspektais: • Primenybė mašinos rūšiai (brand); • Žinojimas, kad yra mašinos tipas, kuris tinka kiekvienam šeimos nariui (reikia trijų tipų).

19. Pavyzdys • Nusprendžiam, kad šiais metais važinėsim su Honda (family of products). • Skambinam Honda pardavėjui (Honda concrete factory): • Man reikia ekonominės, sportinės ir šeimyninės mašinos (abtsract product). • Pardavėjas surašo popierius ir pristato mašinas: Civic, Accord-Wagon ir Prelude (concfrete products).

20. Pasekmės • Esame pririšti prie vienos mašinų šeimos einamuoju momentu (-); • Mašinos tipas pastoviai bus Honda (+). • Prisirišimas vienai šeimai ir yra pagrindinė šablono idėja. • Galim nežinoti, kokio konkrečiai mašinos modelio mums reikia (concrete product), vistiek gausim tinkamą produktą.

21. Pasekmės • Esame priklausomi nuo pardavėjo pasiūlymų. • Nežinodami konkrečių pasiūlymų, vistiek gauname naujausius ir labiausiai tinkamus pasiūlymus. • Pvz. Prašome Honda Prelude, kai iš tikrųjų mums reikia tiesiog “fast Honda”. • Ir gausime Prelude, nors mums geriau būtų tikusi NSX. • Taip yra todėl, kad turime žinių apie produktą ir prašome konkretaus, vietoj to, kad prašyti mums labiausiai tinkamo (fast Honda). • Pardavėjas pastoviai atnaujina gamintojų siūlomų mašinų pasiūlą ir nuo to pelnosi visi klientai.

22. Pavyzdys • Windows XP naudoja AbstractFactory šabloną, Windows Forms elementų šeimų sukūrimui.

23. Realizacija

24. Klasių diagrama

25. Fabrikų realizacija 28-47 eilutės

26. Produktų realizacija 1-27 eilutės

27. Kliento realizacija 48-71 eilutės

28. Realizacija • Naudojant AbstractFactory šabloną, objektų grupės kūrimo procesas nepriklauso nuo jokių konkrečių klasių. • Šį kūrimo procesą aprašantis programinis kodas gali būti visais atvejais toks pats. • Peradresavus AbstractFactory tipo nuorodą galima pakeisti programoje vienos klasių grupės objektus kitos klasių grupės objektais

29. Realizacija • Per nuorodą factory galima prieiti prie vieno ar kito pasirinkto konkretaus fabriko. • Kiekviena iš konkrečių fabrikų klasių yra skirta savo grupės egzemplioriams kurti, tačiau šių konkrečių produktų kūrimo metodai grąžina atitinkamos abstrakčios bazinės klasės tipo nuorodas: AbstractProductA arba AbstractProductB. • Kūrimo metu klientui nereikia nurodyti konkrečių kuriamų objektų klasių.

30. Realizacija • Paprastumo dėlei sąlygos sakinyje kuriami konkretūs fabrikai, tačiau tai nekeičia šablono bendrumo. • Vietoj sąlygos sakinio, nuorodos factory priskyrimui gali būti naudojamas specialus metodas, grąžinantis AbstractFactory tipo nuorodą. • Priklausomai nuo kliento pasirinkimo bus iškviečiamas vienos ar kitos konkrečių produktų grupės metodas product. • Taip bus naudojami vieną ar kitą savybę turinčios grupės objektai.

31. Realizacijos pavyzdys

32. Klasių diagramos pavyzdys

33. Proxy Pattern (Structual) • Proxy: • įgaliojimas; • įgaliotinis, pavaduotojas • by proxy: pagal įgaliojimą;

34. Proxy • Suteikia pakaitalą kitam objektui, kuris valdytų priėjimą prie jo. • Atskiria interfeisą nuo realizacijos. • Tikrasis objektas ne visada bus sukurtas, priklausomai nuo vykdymo, vietos ar priėjimo apribojimų. • Provide a surrogate or placeholder for another object to control access to it.

35. Motyvacija • Turime ‘image viewer’ programą. • Ji turi išvardinti ir parodyti foto objektus, esančius kataloge. • Ne visada reikia peržiūrėti visus paveikslėlius: • Kartais ieškome konkrečios nuotraukos; • Kartais norim matyti tik paveikslėlio pavadinimą. • Viewer’is turi išvardinti visus foto objektus, bet jie neturi būti užkraunami į atmintį iki tol, kol jie turi būti atvaizduojami.

36. Real life pavyzdys • Čekis yra lėšų, esančių sąskaitoje, pakaitalas. Vietoj grynų pinigų galime naudoti čekį ir taip kontroliuoti priėjimą prie sąskaitos.

37. Pasekmės • Proxy šablonas suteikia netiesioginį būdą priėjimui prie objekto. • Šio priėjimo panaudojimas priklauso nuo Proxy tipo: • Virtual proxy: optimizuoja objektų kūrimą, kurdamas juos pareikalavus (on-demand) • Remote proxy: gali paslėpti faktą, kad objektas yra patalpintas kitu adresu. • Protection Proxy: tarpininkas kontroliuoja priėjimą prie RealSubject metodų, suteikdamas priėjimą vieniems objektams ir atsakydamas kitiems.

38. Klasių diagrama

39. Klasių diagramos dalyviai • Subject – interfeisas, realizuotas RealSubject ir atvaizduojantis jo paslaugas. • Interfeisas turi būti realizuotas ir Proxy’je, kad proxy galėtų būti naudojamas bet kurioje vietoje, kur ir RealSubject. • Proxy: • Turi nuorodą, kuri leidžia Proxy prieiti prie RealSubject. • Realizuoja tą patį interfeisą, kaip ir Realsubject, kad Proxy būtų galima naudoti vietoj RealSubject. • Valdo priėjimą prie RealSubject ir gali būti atsakingas už jo sukūrimą ir sunaikinimą. • RealSubject – tikrasis objektas, kurį atvaizduoja Proxy.

40. Aprašymas • Klientas įgyja nuorodą į Proxy ir traktuoja jį taip pat, kaip ir RealSubject – iškviečia metodą doSomething(). • Tuo momentu Proxy gali atlikti skirtingus veiksmus prieš iškviečiant RealSubject metodą doSomething(). • Sukurti RealSubject objektą; • Nustatyti pirmines būsenas; • Patikrinti kliento leidimus iškviesti metodą ir tada iškviesti objekto metodą. • Po doSomething() metodo iškvietimo galima atlikti papildomas užduotis: pvz. padidinti nuorodų į objektą skaičių.

41. Sekų diagrama

42. Virtual Proxy pavyzdys • Programa, parodo didelės raiškos nuotraukų sąrašą ir jas atvaizduoja. • Turi parodyti visų nuotraukų sąrašą, tačiau neturi parodyti tikrų nuotraukų, kol vartotojas jų nepasirenka iš sąrašo.

43. Image interfeisas Atitinka Subject Konkretūs Imige turi realizuoti showImage() metodą, skirtą parodyti paveiksliuką ekrane.

44. Proxy realizacija Image proxy yra virtualus tarpininkas, kuris sukuria ir užkrauna tikrą paveikslėlį to pareikalavus.

45. RealSubject realizacija HighResolutionImage užkrauna paveikslėlį iš disko ir atvaizduoja ekrane, kuomet showImage() yra iškviečiamas

46. Image Viewer programa

47. Image Viewer aprašas • Programa paprasčiausiai užkrauna tris paveikslėlius ir atvaizduoja tik vieną paveikslėlį: vieną kart naudojant šabloną, kitą kartą tiesiogiai. • Kuomet naudojame šabloną, net jei trys paveikslėliai buvo užkrauti, High Resolution image nėra užkraunamas į atmintį, kol jo nereikia atvaizduoti. • Kuomet nenaudojame šablono, trys paveikslėliai užkraunami į atmintį, nors tik vienas yra atvaizduojamas.

48. Pabaiga