nyílt fejlesztőrendszerek plugin fejlesztés – tervezési minták

Budapest University of Technology and Economics

Fault-tolerant Systems Research Group

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

2Budapest University of Technology and Economics


Eclipse platform

Sok fejlesztőHatalmas APISok komponensRengeteg extension pointRengeteg funkcióHogyan lehet kézben tartani a fejlesztést?

− Szabályok!− Tervezési minták!



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



Újrafelhasználás - alapkoncepció



Újrafelhasználás - evolúció

0. „mindent a kályhától”1. Copy-paste2. Függvény könyvtárak3. Objektumok4. Osztály könyvtárak (class libraries)5. Tervezési minták, minta nyelvek6. Komponens technológiák7. Keretrendszerek (frameworks), vállalati

sablonok



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.



Tervezési minta - adatok

1. Azonosítás1. Név2. Kategorizálás3. Kulcsszavak4. Ismert alkalmazások5. Kapcsolódó minták

2. Probléma1. Motiváció2. Cél

3. Megoldás1. Struktúra2. Résztvevők3. Együttműködésük4. Implementáció5. Kód minták

4. Következmények1. Előnyök2. Hátrányok3. Alkalmazhatóság



Tervezési minta megadás -példa



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



Tervezési minták leírása

Hagyományos− Szövegszerkesztő + rajzolóprogram− Szabad kéz a kötelező és opcionális elemek

terénTö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)



Alapvető tervezési minták



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



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



Factory method

Megoldás: elkerülhető a specifikus osztályok bedrótozása a kódba



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



Tervezési minták - Eclipse

A legfontosabb részek mintákat kínálnakÉs mintákat használnakA kiterjesztések megvalósításához



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




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?




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ó!




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…




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




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




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.




Példa – bedrótozott kiterjesztés




Példa – bedrótozott kiterjesztésInterfészt ad meg a kliens




Példa – bedrótozott kiterjesztésAz implementáló osztályt példányosítjuk




Példa – utólagos kiegészítés

Az utólag elkészült extension osztály





Az adapter factory, mely tartalmaz egy listát az extension-ökről





Az adapter factory getAdapter metódusa. Az adott objektumhoz és adapterhez tartozó extension példányt kell visszaadni.





Regisztrálni kell az AdapterFactory-t. Ezt a plugin start metódusában vagy statikus inicializáló blokkjában érdemes megtenni.




Példa – utólagos kiegészítés – összefoglaló modell




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



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



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



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!



Erőforrások

Példa: IFile

Csak az elérési utat és a workspace-t ismeri



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



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



Erőforrások

Handle− Mivel a handle állapot nélküli, biztosan nem

tárol érvénytelen állapotot a kliensben.



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



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()




Az IResource közös ősA getParent() művelet csak a handle-kre alapozva teszi lehetővé a navigációt




Közös ős az összetett objektumok számáraA gyerekek bejárhatóak a members() hívással

De van jobb megoldás…



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



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



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




Tárolja a Listenereket




A listener megkapja az értesítést




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




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



Batch változtatások

Minden eseményvezérelt rendszerben veszélyes a túl sok esemény érkezése

Lehetőség van atomi kompozit akciók létrehozására

− IWorkspaceRunnable− Atomi futtatás− Csak egy értesítés keletkezik, a futás végén



Batch változtatások - példa

Az „execute around method” minta alapján A run() metódus az execute-around metódus



Erőforrások->Java elemek - Adapter

Az erőforrás-struktúra− Fájlok és mappák

A Java-centrikus nézet− A Java modell struktúrája – osztályok,

csomagok, …

A Java nézetben más API-val akar dolgozni a felhasználó

− Tipikus eset az adapter mintának




IJavaElement.getCorrespondingResource() – a mögöttes erőforrás – nem mindig van!− Vannak Java elemek, melyek a workspace-en kívül vannak,

nincs erőforrás megfelelőjük− Java elemek, melyek metódusokat reprezentálnak




Az IJavaElement lehetővé teszi a mögöttes erőforrások elérését

Szükség lehet a másik irányra is!− Facade: JavaCore – factory metódusok

erőforrásokból Java elem létrehozására -> ezek csak handle-k



Java elemek – (Virtuális) proxy

Hasonló struktúra, mint az erőforrások esetén



A Java modell bejárása

Nincs olyan Visitor megoldás, mint az erőforrásoknál

− A Java fa lusta módszerrel épül fel− Ezért egy teljes bejárás költséges lenne

● A fordítási egységeket értelmezni kell…

− Inkább egyedi keresést alkalmazzunk



A Java modell – változás figyelés

Nagyon hasonló az erőforrásoknál alkalmazotthoz




Az erőforrás deltákkal ellentétben nem mindig a gyökérből indul

A delta csak az eseménykezelés alatt érvényes (erőforrás-felszabadítás)

ExecuteAround: JavaCore.run()




A típushierarchia nem része a fának Ezért külön változás-figyelés van hozzá



Eredmények gyűjtése - Builder

A Java Core több olyan elemet tartalmaz, melyek működése után egy eredménylista keletkezik

− A search egy találati listát generál− A content assist a lehetséges folytatásokat

adja vissza− A Java fordító hibaüzeneteket generál

A lista generálásának és megjelenítésének elválasztását meg kell oldani.



Eredmények gyűjtése - Builder

Builder: Válasszuk el egy komplex objektum létrehozását és ábrázolását, hogy ugyanaz a konstruktor más-más reprezentációhoz vezethessen.

Hasonló a Factory-hoz. A Builder komponensek neve Requestor-

ra vagy Collector-ra végződik (Eclipse konvenció)



Eredmények gyűjtése – Builder Példa: Search

A SearchEngine végzi a keresést, és értesíti az IJavaSearchResultCollector-t



Eredmények gyűjtése – Builder Példa: Search

Gyűjti a találatokat. Az aboutToStart() a kezdést jelzi, az accept az egyes találatokat.



Eredmények gyűjtése – Builder Példa: Content Assist

Lehetséges folytatásokat keres




Az eredményeket típus szerint jelenti



UI Workbench – Lusta betöltés

A workbench számos extension point-ot definiál

Fontos a lazy load tulajdonság megteremtése, hogy ne kelljen minden extension-t betölteni

Példa: akciók Csak a deklaráció töltődik be (plugin.xml)

− Vrtuális proxy minta




Maga az Action a plugin.xml információi alapján készül. A run() kivételével mindent tud




Az implementáció csak a run() hívásakor töltődik be



UI Workbench – Állapotmegőrzés

User continuity rule: „Preserve the user interface state across sessions.”

Az állapot-tárolással kapcsolatos követelmények

− Robosztus, könnyen bővíthető− Komplex struktúrákat is támogatnia kell− Tetszőleges objektumot el kell tudni menteni

és visszatölteni



UI Workbench – Állapotmegőrzés

Memento: Az integritás megsértése nélkül tegyük lehetővé az objektum állapotának kimentését, amiből később az állapot visszaállítható.

Az Eclipse XML-alapú formátumot használ



UI Workbench – Editor és View visszaállítás

Sok editor és view lehet aktív De csak kevés látszik egyszerre Visszaállításkor nem kell mindet betölteni

− Mert ez sok plugin aktiválásához vezetne

Proxy-kat kell használni Kooperációt igényel: Ha le akarjuk kérni

az editorok listáját, csak a proxy-kat kérjük le.



UI Workbench – Editor és View visszaállítás



Példa: ISafeRunnable

for (Iterator all=getListeners().iterator();all.hasNext())

{

IMyExstension ext = (IMyExtension)all.next();

ISafeRunnable runnable = new ISAfeRunnable() {

public void handleException(Throwable exception){

all.remove();

}

public void run() throws Exception {

ext.execute(); //hívom az extensiont

}

};

Platform.run(runnable);

}

Végigmegyünk az extension-ökön

nyílt fejlesztőrendszerek plugin fejlesztés – tervezési minták

Documents