Nyílt Fejlesztőrendszerek Plugin fejlesztés – tervezési minták

1. Nyílt FejlesztőrendszerekPlugin fejlesztés – tervezési minták

2. Eclipse platform • Sok fejlesztő • Hatalmas API • Sok komponens • Rengeteg extension point • Rengeteg funkció • Hogyan lehet kézben tartani a fejlesztést? • Szabályok! • Tervezési minták!

3. Patternek • Szoftver újrafelhasználás • Fejlesztési célok • Gyorsaság • Minőség • Elfogadható ár • Újrafelhasználhatóság céljai és lehetőségei • Gyorsítja a fejlesztést • Biztonságosabb megoldásokat kínál • Megkönnyíti a fejlesztők dolgát

4. Újrafelhasználás - alapkoncepció

5. Újrafelhasználás - evolúció • 0. „mindent a kályhától” • 1. Copy-paste • 2. Függvény könyvtárak • 3. Objektumok • 4. Osztály könyvtárak (class libraries) • 5. Tervezési minták, minta nyelvek • 6. Komponens technológiák • 7. Keretrendszerek (frameworks), vállalati sablonok

6. Minták - alapfogalom • Általános minták: • Olyan, sokak által ismert formátumban dokumentált megoldásváz, amelynek alkalmazhatósága könnyen eldönthető egy adott probléma esetén, a végleges megoldás útmutató segítségével könnyen létrehozható. • SW minták: • Egymással kapcsolatban álló osztályok és objektumok, amelyek együtt egy adott objektum-orientált tervezési feladat vagy probléma megoldását szolgálják.

7. Tervezési minta - adatok • Azonosítás • Név • Kategorizálás • Kulcsszavak • Ismert alkalmazások • Kapcsolódó minták • Probléma • Motiváció • Cél • Megoldás • Struktúra • Résztvevők • Együttműködésük • Implementáció • Kód minták • Következmények • Előnyök • Hátrányok • Alkalmazhatóság

8. Tervezési minta megadás -példa

9. Tervezési minta felhasználás • Implementálás fázisai: • Keresés • Név • Felhasználási terület • Kulcsszavak • Kiválasztás • Előnyök, hátrányok • Alkalmazhatóság • Készítés – jól bevált ötletek • Felhasználás - implementálás

10. Tervezési minták leírása • Hagyományos • Szövegszerkesztő + rajzolóprogram • Szabad kéz a kötelező és opcionális elemek terén • Törekvések • Egységes formátum, tool támogatás, katalogizálás és visszakereshetőség segítése • Nyelvek • PCML (Pattern & Component Markup Lang.) • RAS (Reusable Asset Specification)

11. Alapvető tervezési minták

12. Factory method • Egy objektum létrehozásakor egy interfészt definiálunk, de a leszármazott osztályok eldönthetik, hogy milyen oszályt példányosítanak valójában

13. Factory method • Cél: • Komplex objektum létrehozása • Egy specifikus implementációból • Azonos konstruktor különböző implementációkhoz • Megoldott esetek: • Ha egy t kell példányosítania • Ha egy osztály a gyerekeire akarja hagyni a példányosítandó osztály meghatározását

14. Factory method • Megoldás: elkerülhető a specifikus osztályok bedrótozása a kódba

15. Tervezési minták • Még sok, jól bevált van • Általános minták • Vállalati minták • … • Ajánlott irodalom: • Gamma et. Al.: Design Patterns

16. Tervezési minták - Eclipse • A legfontosabb részek mintákat kínálnak • És mintákat használnak • A kiterjesztések megvalósításához

17. Core runtime - IAdaptable • Alapprobléma • Az Eclipse kiterjeszthető platform • Új funkciók, új komponensek jönnek létre • Az új elemek feldolgozásához meg kellene változtatni az API-t? • Nem lenne elég stabil az interfész • A már meglevő részek működését is befolyásolni kell – hogyan? • Az alap Java nem segít

18. Core runtime - IAdaptable • Példa • Az Eclipse elválasztja a megjelenítést a működéstől • Pl. IFile, IFolder, IProject – a fájlrendszer elemeinek absztrakciói – nincs megjelenítés • Lehetne: IUIFile, … • Nem jó, mert minden új elemhez új UI interfész is kellene (overhead) • Hogyan jelenítsük meg az elemeket?

19. Core runtime - IAdaptable • Megoldás - IPropertySource • Egy interfész, melyen keresztül lekérdezhetők az elem megjelenítés-specifikus tulajdonságai • Hogyan implementáljuk? • Közvetlenül… -> nem jó!

20. Core runtime - IAdaptable • Közvetlen implementáció • Túl sok örökölt interfészhez vezethet, nem jó • Az interfész átvételével változik az API, ami nem jó • Ha pl. az IFile tudna a Properties viewról, akkor beépítettünk egy nem kívánatos GUI – Core linket…

21. Core runtime - IAdaptable • Konklúzió • Szükség van egy megoldásra, mely lehetővé teszi: • Egy interfész hozzáadását egy típushoz, anélkül hogy a típust belőle örököltetnénk • Új viselkedést adjunk meglevő típusokhoz (pl. IFile) • Megoldás: Extension Object pattern

22. Core runtime - IAdaptable • Extension Object pattern • Cél: különböző interfészek támogatása anélkül, hogy a típusunknak örökölnie kellene őket • A kliens egy típuskód alapján kérheti le a megfelelő interfészt • Dinamikusan nőhet az interfészek száma • Futásidejű kötés lehetséges az extension-öknél

23. Core runtime - IAdaptable • Extension Object pattern • Kérdések • Objektum vagy osztály szintű extension kezelés -> az Eclipse osztályt szintűt definiál • Új viselkedés megadható, de új tulajdonságok nem! • Hogy adjuk meg a lehetséges extension-öket? -> 2 megoldás • A kiterjeszthető osztály maga adja meg (programozott) • Külső kiterjesztés esetén a Platform osztály segíségével regisztrálunk egy Adapter Factory-t az osztályhoz.

24. Core runtime - IAdaptable • Példa – bedrótozott kiterjesztés

25. Core runtime - IAdaptable • Példa – bedrótozott kiterjesztés Interfészt ad meg a kliens

26. Core runtime - IAdaptable • Példa – bedrótozott kiterjesztés Az implementáló osztályt példányosítjuk

27. Core runtime - IAdaptable • Példa – utólagos kiegészítés Az utólag elkészült extension osztály

28. Core runtime - IAdaptable • Példa – utólagos kiegészítés Az adapter factory, mely tartalmaz egy listát az extension-ökről

29. Core runtime - IAdaptable • Példa – utólagos kiegészítés Az adapter factory getAdapter metódusa. Az adott objektumhoz és adapterhez tartozó extension példányt kell visszaadni.

30. Core runtime - IAdaptable • Példa – utólagos kiegészítés Regisztrálni kell az AdapterFactory-t. Ezt a plugin start metódusában vagy statikus inicializáló blokkjában érdemes megtenni.

31. Core runtime - IAdaptable • Példa – utólagos kiegészítés – összefoglaló modell

32. Core runtime - IAdaptable • Elemek • IAdaptable – a kiegészítendő osztálynak implementálni kell • AdapterFactory – utólagos bővétményeket tárol és példányosít

33. Erőforrások • Erőforrások • Az Eclipse erősen fájlrendszer alapú • Nincs köztes repository • A fájlt vagy közvetlenül (kívülről) vagy az Eclipse-ből módosíthatjuk • Erőforrások • Létrejönnek/módosulnak/törlődnek • Nem akarjuk az állapotot több helyen tárolni • Állapotmentes referencia kell • Eclipse: csak Handle-t kap a kliens

34. Erőforrások • Handle • Két minta összekötése: Proxy és Bridge • Proxy: helyettes létrehozása egy objektum számára, hogy kontrolláljuk a hozzáférést • Hozzáférés kezelés -> érvénytelen állapot kialakulásának elkerülése • Bridge: leválasztja az interfészt és az implementációt, hogy függetlenül módosulhassanak • Az interfész és implementáció erős elválasztása

35. Erőforrások • Alkalmazás a fájlrendszerre: • Egy handle, ami kulcs a fájlhoz • Egy info objektum, mely a fájl állapotát tárolja. Csak egy info implementáció van minden handle-hez. • Handle: IFile, IFolder, IProject, IWorkspaceRoot • Nem implementálandóak!

36. Erőforrások • Példa: IFile Csak az elérési utat és a workspace-t ismeri

37. Erőforrások • Handle • Érték típusok, az egyenlőséget qz equals() metódussal vizsgáljuk • Hash-elhetőek • Több handle mutathat ugyanarra az erőforrásra • Definiálhatják az erőforrás viselkedését, de az állapotát nem tárolhatják • Egy handle mutathat nem létező erőforrásra • Néhány művelet csak a handle-ben levő információkra alapoz, ezek nem létező erőforrás esetén is sikeresek

38. Erőforrások • Handle • Ha egy műveletnek szüksége van az erőforrásra, CoreException-t dob, ha az nem létezik • Létezés tesztelése: exists() • A handle egy szülő handle-ből keletkezik • A handle használható az erőforrás létrehozására is

39. Erőforrások • Handle • Mivel a handle állapot nélküli, biztosan nem tárol érvénytelen állapotot a kliensben.

40. Erőforrások • ResourceInfo • Az elemek állapotát tárolja • Leszármazott osztályok (pl. ProjectInfo) a speciális állapot tárolására • Fa struktúrában tárolódik a teljes workspace információja a memóriában • ->”element tree” • Az info visszaadása a fa bejárásával történik a handle-ben levő path segítségével • Lemezművelet nélkül megtalálhatjuk a keresett elemet

41. Workspace – composite pattern • Az erőforrás fa a composite mintát követi • A composite minta lényege: Fastruktúrába szervezni az elemeket, a köztük levő rész/egész viszony felhasználásával. • A fa gyökere: IWorkspaceRoot • ResourcePlugin.getWorkspace()

42. Workspace – composite pattern Az IResource közös ős A getParent() művelet csak a handle-kre alapozva teszi lehetővé a navigációt

43. Workspace – composite pattern Közös ős az összetett objektumok számára A gyerekek bejárhatóak a members() hívással De van jobb megoldás…

44. Erőforrás bejárás - Visitor • A kódolás elkerülésére alkalmazzuk • Visitor: Egy műveletet valósít meg, melyet egy objektum struktúrán akarunk megvalósítani. • A fa bejárást nem kell megvalósítani, csak egyszer

45. Erőforrás bejárás - Visitor • Struktúra • Az accept() metódus valósítja meg a bejárást, és visszahívja a visitor-t minden elemre • Ha a visit() true-val tér vissza, akkor az elem gyerekeit is be kell járni

46. Erőforrásváltozások követése - Observer • Az erőforrások változhatnak • Az Eclipse-en belüli változtatások miatt • A fájlrendszerhez való újraszinkronizálás miatt • Az állapotváltozásokat követni kell • A klienseknek a hatékony állapot-frissítések miatt szükségük lehet rá • A Workspace-ben kel regisztrálni

47. Erőforrásváltozások követése - Observer Tárolja a Listenereket

48. Erőforrásváltozások követése - Observer A listener megkapja az értesítést

49. Erőforrásváltozások követése - Observer • Kétféle módosítási minta • Push – a listener részletes információkat kap a változásokról • Pull – a listenernek kell lekérdezni az új állapotot • Eclipse: ResourceDelta • Az erőforrás-fa állapot-változását írja le • Önmaga is fa

50. Erőforrásváltozások követése - Observer • A resourceDelta az egyszeres és többszörös változásokat ugyanazzal a struktúrával írja le • Egyszerűen be lehet járni a delta tree-t • Mivel az erőforrások csak handle-k, törölt elemekre is hivatkozhatnak