A fejlesztési felület
Ez a szekció a Delphi fejlesztési felületét és programfejlesztési koncepcióját mutatja be. Itt kerülnek meghatározásra olyan elnevezések is, amelyek a dokumentum további részében magyarázat nélkül szerepelnek.
Gyors referencia:
Ez a tanulmány azt a célt tűzte ki maga, hogy a nyelvet, az új nyelvi elemeket mutassa be. Nem tehetjük azonban ezt meg anélkül, hogy nagy vonalakban át ne tekintenénk a Delphi által nyújtott fejlesztési rendszert.
Ez még inkább igaz a Delphire, hiszen - mint azt már a bevezetőben is említettem - a Delphi célszoftver. Tervezőinek és létrehozóinak célja a Microsoft Windows különböző verziói alatt és alá történő könnyű, gyors, megbízható programok (alkalmazások) fejlesztése, ezeken belül is kiemelkedő hangsúlyt kapott az adatbázis alkalmazások készítésének elősegítése.
Első alapszempont volt, hogy a programozónak minél kevesebbet kelljen törődnie azzal, hogy a Windows alacsony szinten hogyan valósítja meg a problémát (aki fejlesztett Windows alá kizárólag az API segítségével, tudhatja, hogy a programozó energiáinak nagy részét az alacsonyszintű kommunikáció kialakítása köti le), de továbbra is lehetőséget adjon ennek használatára, ha a cél ezt kívánja meg.
A Delphi ezt két szinten oldotta meg. Egyrészt egy eljáráskészletet biztosít az API függvényeinek minél kultúráltabb elérésére, másrészt egy nagyon gondosan és átgondoltan felépített osztály-hierarchiát ad eszközül, amelynek köszönhetően a programozónak az az érzete támad, mintha a Windows-t valóban objektum orientáltan alakították volna ki!
A Delphi megtervezésekor az egyik jelszó a következő volt: Legyen látható tervezési időben, ami csak lehet!
Ennek érdekében a vizuális tervezés és a kódgenerálás szervesen összekapcsolódott, a párbeszédpanelek (újabb kifejezéssel űrlapok) tervezése integrált része lett a rendszernek. (Régebben külön segédprogramok (pl. Workshop) használatával történt meg a vizuális tervezés, s a kód és a párbeszédelemek összekapcsolása és integritásának a fenntartása a programozó feladata volt. Ennek a megoldásnak a másik gyengéje, hogy a párbeszéd elemek tulajdonságai és viselkedése szinte kizárólag fordítási időben volt látható, így a fejlesztést aránytalanul sok fordítás nehezítette.
A fent említett összerendelésnek a megvalósítására vezette be a Delphi a komponens fogalmát. A komponens egy osztály, amely valamely látható (pl. párbeszédpanel vezérlőelemek) vagy nem látható (pl. adatbázis elemek, nyomtató, rendszereszközök, kivételek, sőt maga az alkalmazás) erőforrás interface-ét valósítja meg.
A komponens Borland féle definíciói:
Ez utóbbi definícióban elhangzott a plug-in kifejezés, amely a komponens architektúra igazi erejét adja. Egy - jól megírt - komponens teljes mértékben integrálódik a Delphi rendszerébe, az eredeti komponensekkel egyenrangú alkotóeleme lesz: megjelenik a komponens palettán, felrakhatom az űrlapra, az Object Inspectorban beállíthatom tervezési időben a tulajdonságait. Tehát a Delphi komponens-hierarchiája egy kétirányú eszköz a gyors fejlesztésre.
Mint minden Windows program, a Delphi alkalmazás is párbeszédpanelekre és ablakokra, vagy ahogy újabban együttesen nevezik, űrlapokra épül. (Itt megjegyzendő, hogy lehet a Delphiben konzol-alkalmazást is írni - egy ablakos, szöveges program -, de igazi ereje nem ebben rejlik, tehát ezzel részletesebben nem foglalkozom.)
Minden űrlap a TForm komponensre, vagy a Delphi 2-ben ennek egy leszármazottjára (virtuális űrlap öröklés) épül. Az űrlap által tartalmazott párbeszédelemek ennek a leszármazottnak adatmezői, míg az eseménykezelő eljárások ennek tagfüggvényei. Minden eseménykezelő eljárásnak van egy Sender : TObject paramétere, amely az eseményt generáló objektumot tartalmazza. Erre azért van szükség, mert az űrlap vezérlőelemei által keltett eseményeket nem a vezérlőelemek, hanem az űrlap egy eljárása kezeli le. Másrészt ez lehetőséget ad több vezérlőelem egy bizonyos eseményének vagy - ritkábban - egy vezérlőelem több eseményének egyazon eljárással történő lekezelése.
Az alábbi példa egy űrlap osztályának szerkezetét mutatja be:
A Delphiben az űrlapok és a fordítási egységek (unitok) között szoros kapcsolat van: minden űrlaphoz pontosan egy unit tartozik és egy unithoz legfeljebb egy űrlap tartozhat. Ez azt jelenti, hogy nincs lehetőségünk egy nagy űrlap eljárásait több unitra bontani, s arra sincs lehetőség, hogy két szervesen összetartozó párbeszédpanelt egy unitba tegyünk. Erre az automatikus kódgenerálás és kódszinkronizálás miatt van szükség, de ennek a nagyon szigorú kötésnek a következménye, hogy az űrlapot között globális változókon keresztül kell lebonyolítani az adatkommunikációt.
A RAD (Rapid Application Development; gyors alkalmazásfejlesztés) egy komplex fogalom, amely a hatékony programfejlesztés különböző tényezőit foglalja magába. Az alábbiakban áttekintést nyújtok a RAD elemekről és ezek Delphi-beli megvalósításáról:
A Delphi széleskörű hibakeresési lehetőségeket nyújt. Az integrált debuger segítségével akár soronként követhetjük nyomon a programunk futását. Az elhelyezhető töréspontokat számlálóval vagy akár logikai feltétellel is elláthatjuk. A Watch ablakban nyomon követhetjük a változók értékét, de lehetőség van a hívási verem, a CPU regisztereinek és a Delphi 2-ben a taszkok állapotának megfigyelésére is. Az objektum-tallózóval nyomon követhetjük az öröklődési vonalat, az egyes metódusok vagy adatmezők kódbeli referenciáit is megtekinthetjük. A Delphi 2 ezenkívül rendelkezik egy adatbázis-tallózóval, amely segítségével gyorsan áttekinthetjük adatbázisainkat is.
Nagyon hiányzik az editorból egy makrorögzítő, amellyel gyakran használt tevékenységeket automatizálhatnánk.
|
|
 |
|
|
|
|
|
Az IDE |
