Object Oriented Programming with Free Pascal and Lazarus/hu: what changed

Revision 1 to 2. Removed lines have a minus sign; added lines have a plus sign.

Old	New		Line
1		-	~~<font size="6">Objektum-orientált programozás Free Pascal-lal és Lazarus-szal</font>~~
	1	+	Objektum-orientált programozás Free Pascal-lal és Lazarus-szal
2	2
3	3		## Bevezetés
4	4
5	5		Rengeteg kitűnő tananyag található a Pascal-ról, de ennek a leírásnak a célja továbbvinni a kezdőket az [[Glossary\|objektum-orientált programozás]] világába, ami a szabványos Pascal kiegészítése. Ezt a kiegészítést a Turbo-Pascal, a Delphi és a Free Pascal / Lazarus tartalmazza.
6	6
7	7		Az [[Glossary\|Objektum]] a szabványos Pascal-ban definiált [rekord](http://wiki.lazarus.freepascal.org/Record) struktúra kibővítése.
8	8
9	9		A hagyományos szöveges módú Pascal programozás megfelelő olyan programok készítésére - mint például a hagyományos Unix alkalmazások -, amelyek egy dolgot tudnak csinálni, de azt nagyon jól. Az a bizonyos "egy dolog", amit az alkalmazás csinál elég bonyolult lehet, és akár több menüből elérhető lehetőséget kínálhat a felhasználónak, de alapvetően csak parancsok kiadására szorítkozik, amelyeket a felhasználó kiad a billentyűzet segítségével, és a választ a monitoron vagy a nyomtatón kapja meg.
10	10
11	11		Ahhoz, hogy egy [[Glossary\|grafikus felhasználói felületet (GUI)]] hozzunk létre, általában szükséges bevonni a dolgokba valamilyen objektum-orientált programozási metódust (gyakran a [[Glossary\|C]] nyelv vagy valamelyik variánsának használatával, Visual Basic-kel, vagy valamelyik [[Glossary\|OO]] variánsával a Pascal-nak, úgymint a [[Glossary\|Free Pascal]] a [[Glossary\|Lazarus]]-szal vagy nélküle).
12	12
13	13		Egy GUI-ban a felhasználónak rendelkezésére áll egy képernyő, nagy mennyiségű szervezetten elrendezett képpel és ikonnal, amelyek eszközkészletekből, [[Glossary\|Widget]]-ekből állnak, amelyekhez különféle események vannak hozzárendelve, úgy mint
14	14
15	15		- kiválasztás egy menüből,
16	16		- fájlok megnyitása, vagy mentése,
17	17		- csatlakozás az internethez,
18	18		- numerikus műveletek végrehajtása, stb.
19	19
20	20		A felhasználó feladata mozgatni az egeret vagy kijelölő eszközt a képernyőn, hogy eseményeket válasszon ki, amelyek végrehajtódnak egérgomb-, vagy billentyű lenyomására.
21	21
22	22		Annak ellenére, hogy minden komplex grafikus felhasználói felülettel rendelkező rendszer megírható Pascal-ban, vagy bármely más nyelven, sokkal egyszerűbb objektum-orientált rendszert használni, ahol minden grafikus objektumnak a képernyőn lehetnek saját tulajdonságai és függvényei, így együtt egy összefüggő szerkezetet alkotva.
23	23
24	24		Már a tárgyalás elején le kell szögeznünk az osztály és az objektum közötti fontos logikai különbséget: az osztály egy leírás, amely alapján a fordító példányosítás segítségével létrehozza az objektumot.
25	25
26	26		Sajnos Pascal-ban ez az egyszerű logika csorbát szenved, mert object (objektum) és class (osztály) is deklarálható, illetve példányosítható. A kettő között a különbséget a futási időben elfoglalt memóriaterület helye jelenti: az osztály (class) egy objektumra mutató mutató (pointer). Ez azt jelenti, hogy az osztály a program HEAP területén helyezkedik el, míg az objektum a stack-en.
27	27
28	28		Ennek ellenére - mivel az object típust ritkán alkalmazzuk - nyugodtan használhatjuk az első logikai gondolatmenetet.
29	29
30	30		## Objektumok - a való világ analógiája
31	31
32	32		Vegyük például a vérminta analógiáját, amit egy kórházban vagy az orvosi rendelőben gyűjtenek be.
33	33
34	34		### Vérminta
35	35
36	36		A minta fizikálisan természetesen egy objektum; létezik - vele összefüggésben - rengeteg információ, dokumentum, és egyéb fizikai objektum.
37	37
38	38		- Kémcső, olyan típusú, amelyet a teszt előír.
39	39
40	40		- Helyi szabályozás (vagy metódus, szabványos művelet) amely a nővér vagy technikus munkáját irányítja
41	41		- milyen kémcsövet használjon,
42	42		- hogyan dolgozza fel a mintát
43	43		- hogyan tárolja a laborba való szállításig.
44	44
45	45		- Címke a kémcsövön a részletekkel:
46	46		- minta azonosító
47	47		- a páciens neve és születési dátuma
48	48		- a mintavétel időpontja
49	49		- a szükséges tesztek.
50	50
51	51		- Igénylőlap, amivel a mintát a laborba küldik:
52	52		- minta azonosító
53	53		- az igénylő azonosítója
54	54		- az igényelt vizsgálatok
55	55		- bővebb információk a páciensről
56	56		- a lehetséges diagnózis, amelynek a megerősítését kérik.
57	57
58	58		Az igénylőlap másolatát elhelyezik a páciens kartonjában, hogy emlékeztesse az orvost arra, hogy adott időn belül eredményeket fog kapni.
59	59
60	60		- A laborban - helyi metódusok, amelyek meghatározzák:
61	61		- hogyan kell a mintát analizálni,
62	62		- milyen eszközöket kell használni,
63	63		- hogyan kell az eszközöket kalibrálni, és működtetni,
64	64		- milyen formában kell tárolni az eredményeket, és
65	65		- hogyan kell visszajelenteni az orvosnak.
66	66
67	67		A tényleges eredmény egy rekord, amelyet az orvos a diagnózis felállításához használ, továbbá egy másolat kerül elhelyezésre a páciens kartonjában.
68	68
69	69		A fizikai minta megmaradhat referenciának, igazolásnak vagy további tesztekhez, vagy megsemmisítik valamilyen módon; ehhez egy további metódus szükséges, ami ennek a módját meghatározza.
70	70
71	71		Nincs szükség orvosra, hogy kitalálja az összes részletet és utasítást minden alkalommal, amikor egy mintát begyűjtenek; sőt, lehet, hogy alig van tudomása arról, hogy hogyan értékelnek ki egy mintát a laborban. A különféle eljárások öröklődnek az előző mintavételekből és analízisekből - így lesz egy általános terv az egész folyamatra - és így együtt, az összes dokumentummal, adattal, és a hozzájuk tartozó metódusokkal a vérmintát, egy komplex objektumként tekinthetjük.
72	72
73	73		Az orvos képzeletében, a vérminta többnyire ugyanannak az entitásnak jelenik meg, mint az eredményei. A nővéreknek és technikusoknak pedig a minta, a kémcső, a címke, és a tárolási feltételek szintén egy entitást jelentenek.
74	74
75	75		### Egy másik példa - az automobil
76	76
77	77		Ha nem szereted a vért, hasonló okfejtés használható egy autóra is. Ez a példa talán valamivel közérthetőbb. Az autónak a fizikai megjelenésén kívül, egyéb technikai paraméterei is vannak - ezek lesznek az autó objektumunk mezői. Az autónak működnie is kell valamilyen előre meghatározott leírás szerint. A működés több részfolyamatból áll, ezeket a részfolyamatokat nevezzük metódusoknak.
78	78
79	79		Összefoglalva:
80	80
81	81		Az autó mezői:
82	82
83	83		- szín
84	84		- maximális sebesség
85	85		- sebességfokozatok száma
86	86		- ajtók száma
87	87		- utasok maximális száma
88	88		- az éppen bent ülő utasok száma
89	89		- aktuális sebesség
90	90
91	91		Az autó metódusai:
92	92
93	93		- motor indítás
94	94		- gyorsítás
95	95		- lassítás
96	96		- sebességváltás
97	97
98	98		## Programozási példa
99	99
100	100		Az elméleti fejtegetés után térjünk rá arra a kérdésre, hogy hogy néz ki programozási szempontból egy objektum! Ez a szekció ugyan fel van osztva részekre, de érdemesebb egyben olvasni a teljes kép megalkotásához.
101	101
102	102		### Deklaráció
103	103
104	104		Ehhez vegyük alapul az automobilunkat; először is leírást kell készítenünk a mezőkről és a metódusokról:
105	105
106	106		``` pascal
107	107		type
108	108		TAutoMobil = class
109	109
110	110		{ Mezők: }
111	111
112	112		FSzin: String; { Az autó színe. }
113	113		FMaxSebesseg: Real; { Maximális sebesség. }
114	114		FMaxUtasok: Integer; { Utasok maximális száma. }
115	115		FAktualisSebesseg: Real; { Az aktuális sebesség. }
116	116		FAktualisUtasok: Integer; { A bent ülő utasok maximális száma. }
117	117
118	118		{ Metódusok: }
119	119
120	120		constructor Create(aSzin: String; aMaxSebesseg: Real; aMaxUtasok: Integer);
121	121		procedure Gyorsit;
122	122		procedure Lassit;
123	123		end;
124	124		```
125	125
126	126		### Implementáció
127	127
128	128		Az előző példában jól látható a rekordhoz való hasonlóság, illetve az eltérés is abban, hogy itt már metódusok is lettek definiálva. A metódusokat és mezőket szintén a pont operátorral érhetjük el. Azonban ez a deklaráció még nem teljes! A metódusokat - akár a unit-oknál - ki kell fejtenünk a főprogram szekciójának megkezdése előtt:
129	129
130	130		``` pascal
131	131		{ ...deklarációs rész... }
132	132
133	133		constructor TAutoMobil.Create(aSzin: String; aMaxSebesseg: Real; aMaxUtasok: Integer);
134	134		begin
135	135		Self.FSzin := aSzin;
136	136		Self.FMaxSebesseg := aMaxSebesseg;
137	137		Self.FMaxUtasok:= aMaxUtasok;
138	138		end;
139	139
140	140		procedure TAutoMobil.Gyorsit;
141	141		begin
142	142		end;
143	143
144	144		procedure TAutoMobil.Lassit;
145	145		begin
146	146		end;
147	147
148	148		{ ...további programrészek... }
149	149		```
150	150
151	151		Vegyük észre a Self saját magára mutató objektumot. Ennek a haszna az, hogy az aktuális objektum egy mezőjére hivatkozhatunk vele. A létjogosultsága abban rejlik, hogy a metódusokon belül deklarálható létező mezővel megegyező azonosítójú változó, illetve függvény; így azonban megkülönböztethetjük őket.
152	152
153	153		### Példányosítás (konstruktor)
154	154
155	155		Ne felejtsük el, hogy a deklaráció és a kifejtés még csak egy leírás - tervnek is tekinthetjük - az autóról. Ez azt jelenti, hogy még le kell gyártani - példányosítani kell. Erre szolgál az eddig talán ismeretlen constructor (konstruktor). Mint látható, nincs hozzá definiálva visszatérési érték, mégis értékadásra használjuk. Ennek az az oka, hogy alapértelmezetten egy pointer-rel és csak azzal térhet vissza. A pointer arra az objektumra mutat, amelyet létrehoztunk a konstruktorral. Talán kicsit bonyolultan hangzik elsőre, de lássuk a példát:
156	156
157	157		``` pascal
158	158		var
159	159		Auto: TAutoMobil;
160	160
161	161		begin
162	162		Auto := TAutoMobil.Create('Fekete', 160, 5);
163	163		end;
164	164		```
165	165
166	166		Ezzel az egy sorral létrehoztuk az autónkat, amely fekete színű, 160 km/h a végsebessége, és 5 utas fér el benne. Ezek után már beindíthatjuk, gyorsíthatunk, lassíthatunk vele, stb.:
167	167
168	168		``` pascal
169	169		var
170	170		Auto: TAutoMobil;
171	171
172	172		begin
173	173		Auto := TAutoMobil.Create('Fekete', 160, 5);
174	174
175	175		Auto.Gyorsitas;
176	176		Auto.Lassitas;
177	177		end;
178	178		```
179	179
180	180		### Megsemmisítés (destruktor)
181	181
182	182		Mielőtt továbbmennénk, el kell fogadnunk, hogy az autó egy veszélyes hulladék. Ezért a szabályos megsemmisítésről gondoskodnunk kell. Ez a megsemmisítés szintén egy metódus, amely leírja, hogy mi a teendő megsemmisítés esetén. Ezt a metódust hívjuk destruktornak (destructor). A destruktort szintén deklarálni kell, majd pedig kifejteni. Ezzel kibővítve a deklarációnkat:
183	183
184	184		``` pascal
185	185		type
186	186		TAutoMobil = class
187	187
188	188		{ Mezők: }
189	189
190	190		FSzin: String; { Az autó színe. }
191	191		FMaxSebesseg: Real; { Maximális sebesség. }
192	192		FMaxUtasok: Integer; { Utasok maximális száma. }
193	193		FAktualisSebesseg: Real; { Az aktuális sebesség. }
194	194		FAktualisUtasok: Integer; { A bent ülő utasok maximális száma. }
195	195
196	196		{ Metódusok: }
197	197
198	198		constructor Create(aSzin: String; aMaxSebesseg: Real; aMaxUtasok: Integer);
199	199		destructor Destroy;
200	200		procedure Gyorsit;
201	201		procedure Lassit;
202	202		end;
203	203		```
204	204
205	205		A destruktor programozástechnikai jelentősége abban rejlik, hogy az objektum által lefoglalt memóriaterületet felszabadítja. Ez a Pascal-nál (és C++-nál is) nagyon fontos, mivel nincs beépített szemétgyűjtő (mint pl. Java esetén), tehát a már nem szükséges objektumokat "kézzel" kell felszabadítanunk. Természetesen óvatosan kell eljárnunk, nehogy valahol még hivatkozzunk rá. A felszabadított objektumra való hivatkozás a program összeomlásával jár (SIGSEGV hiba), mivel nem létező objektumra mutatunk a hivatkozás során.
206	206
207	207		Ha idáig nem megy készség szinten, ne is folytasd az olvasást, inkább próbáld értelmezni az előzőeket! :)
208	208
209	209		### Tulajdonságok (property-k)
210	210
211	211		Ha eddig minden érthető volt, akkor a dolgokat tovább kell bonyolítanunk azzal, hogy az autó, mint objektum, több egyéb objektumból áll - ezek például: motor, sebességváltó. Ha végig gondoljuk mindegyiknek vannak ugyanúgy mezői és metódusai. A motort, és a sebességváltót készen kapják az autógyárak, és beszerelik az autóba. Azonban ahhoz, hogy be tudják őket szerelni, helyet kell nekik biztosítani: mezőket kell létrehozni a deklarációban:
212	212
213	213		``` pascal
214	214		type
215	215		TAutoMobil = class
216	216
217	217		{ Mezők: }
218	218
219	219		FSzin: String; { Az autó színe. }
220	220		FMaxSebesseg: Real; { Maximális sebesség. }
221	221		FMaxUtasok: Integer; { Utasok maximális száma. }
222	222		FAktualisSebesseg: Real; { Az aktuális sebesség. }
223	223		FAktualisUtasok: Integer; { A bent ülő utasok maximális száma. }
224	224		FMotor: TMotor; { Az autóba szerelt motor. }
225	225		FSebessegValto: TSebessegValto; { Az autóba szerelt sebességváltó. }
226	226
227	227		{ Metódusok: }
228	228
229	229		constructor Create(aSzin: String; aMaxSebesseg: Real; aMaxUtasok: Integer; aMotor: TMotor; aSebessegValto: TSebessegValto);
230	230		destructor Destroy;
231	231		procedure Gyorsit;
232	232		procedure Lassit;
233	233		end;
234	234		```
235	235
236	236		Ez megjelenik a konstruktorban is paraméterként. Így már többféle modell legyártható pl. a motor megváltoztatásával. A sebességváltó vagy a motor cseréje szükséges lehet később is, de amit be szeretnénk szerelni, nem biztos, hogy kompatibilis! Ha kompatibilitási problémánk lehet, akkor nem célszerű közvetlenül az objektum mezőjének értéket adni, mert később komoly, és nehezen visszakövethető hibát okozhatunk vele. Ennek a kiküszöbölésére használhatjuk az objektum metódusait is, ahol értékadás előtt vizsgálatot hajtunk végre, illetve a Pascal-ban egy elegáns megoldás a tulajdonságok (property-k) használata, amelyek ezt megold(hat)ják helyettünk. Deklarálhatunk írható-olvasható, és csak olvasható tulajdonságokat is. Egy autó kapcsán szinte minden cserélhető egymással, de most kivételesen vegyük az alvázszámot nem megváltoztathatónak (mivel tilos megváltoztatni). Ezt a gyárban egyszer beütik, és onnantól a megsemmisítésig ugyanaz az érték marad. Ehhez a property, a read, és a write kulcsszókat kell használnunk:
237	237
238	238		``` pascal
239	239		type
240	240		TAutoMobil = class
241	241
242	242		{ Mezők: }
243	243
244	244		FSzin: String; { Az autó színe. }
245	245		FMaxSebesseg: Real; { Maximális sebesség. }
246	246		FMaxUtasok: Integer; { Utasok maximális száma. }
247	247		FAktualisSebesseg: Real; { Az aktuális sebesség. }
248	248		FAktualisUtasok: Integer; { A bent ülő utasok maximális száma. }
249	249		FAlvazSzam: String; { A gyárban beütött alvázszám. }
250	250		FMotor: TMotor; { Az autóba szerelt motor. }
251	251		FSebessegValto: TSebessegValto; { Az autóba szerelt sebességváltó. }
252	252
253	253		{ Metódusok: }
254	254
255	255		constructor Create(aSzin: String; aMaxSebesseg: Real; aMaxUtasok: Integer; aMotor: TMotor; aSebessegValto: TSebessegValto);
256	256		destructor Destroy;
257	257		procedure Gyorsit;
258	258		procedure Lassit;
259	259		procedure SetMotor(aMotor: TMotor);
260	260		procedure SetSebessegValto(aSebessegValto: TSebessegValto);
261	261
262	262		{ Tulajdonságok: }
263	263
264	264		property AlvazSzam: String read FAlvazSzam; { Csak olvasható tulajdonság. }
265	265		property Motor: TMotor read FMotor write SetMotor; { Olvasható és írható tulajdonság. }
266	266		property SebessegValto: TSebessegValto read FSebessegValto write SetSebessegValto;
267	267		end;
268	268		```
269	269
270	270		Ezek után nézzük, hogy mit is csinál pl. a SetSebessegValto fuggvény:
271	271
272	272		``` pascal
273	273		{ ...deklarációs rész... }
274	274
275	275		procedure TAutoMobil.SetSebessegValto(aSebessegValto: TSebessegValto);
276	276		begin
277	277		if (IsCompatibleSebessegValto(aSebessegValto) = True) then
278	278		begin
279	279		Self.FSebessegValto := aSebessegValto;
280	280		end
281	281		else Self.FSebessegValto := null;
282	282		end;
283	283
284	284		procedure TAutoMobil.Lassit;
285	285		begin
286	286		end;
287	287
288	288		{ ...további programrészek... }
289	289		```
290	290
291	291		A példában használt IsCompatibleSebessegValto függvény valahol az osztályon kívül definiált. A tartalmával nem fontos a példa szempontjából foglalkozni. A lényeg, hogy megállapítja, hogy a beszerelni kívánt sebességváltó kompatibilis-e az autóval. Ha igen, akkor bekerül, ha nem, akkor nem kerül be sebességváltó (feltételezzük, hogy a régi sebességváltó már ki lett szerelve).
292	292
293	293		### Virtuális metódusok
294	294
295	295		Megállapíthatjuk, hogy egy adott gyártó egy adott típusú automobilból gyárt többféle változatot, pl. mechanikus és elektromos gázpedállal is. Ebben az esetben az alapvető funkciók megegyeznek, de kicsi eltérések vannak. Ilyen alapvető funkciók pl. a gyorsítás, a lassítás, stb. Ezért ezeket a különböző példányokban különbözőképpen kell megvalósítani. Erre valók a virtuális metódusok, amelyeket a virtual kulcsszóval deklarálhatunk. Alapul véve az előbbi gondolatmenetet, így fog kinézni a TAutoMobil osztályunk:
296	296
297	297		``` pascal
298	298		type
299	299		TAutoMobil = class
300	300
301	301		{ Mezők: }
302	302
303	303		FSzin: String; { Az autó színe. }
304	304		FMaxSebesseg: Real; { Maximális sebesség. }
305	305		FMaxUtasok: Integer; { Utasok maximális száma. }
306	306		FAktualisSebesseg: Real; { Az aktuális sebesség. }
307	307		FAktualisUtasok: Integer; { A bent ülő utasok maximális száma. }
308	308		FAlvazSzam: String; { A gyárban beütött alvázszám. }
309	309		FMotor: TMotor; { Az autóba szerelt motor. }
310	310		FSebessegValto: TSebessegValto; { Az autóba szerelt sebességváltó. }
311	311
312	312		{ Metódusok: }
313	313
314	314		constructor Create(aSzin: String; aMaxSebesseg: Real; aMaxUtasok: Integer; aMotor: TMotor; aSebessegValto: TSebessegValto);
315	315		destructor Destroy;
316	316		procedure Gyorsit; virtual;
317	317		procedure Lassit; virtual;
318	318		procedure SetMotor(aMotor: TMotor);
319	319		procedure SetSebessegValto(aSebessegValto: TSebessegValto);
320	320
321	321		{ Tulajdonságok: }
322	322
323	323		property AlvazSzam: String read FAlvazSzam; { Csak olvasható tulajdonság. }
324	324		property Motor: TMotor read FMotor write SetMotor; { Olvasható és írható tulajdonság. }
325	325		property SebessegValto: TSebessegValto read FSebessegValto write SetSebessegValto;
326	326		end;
327	327		```
328	328
329	329		A virtual kulcsszóval deklarált függvényeket később az öröklődés során létrehozott gyerek osztályok metódus implementációiban módunkban áll módosítani. Ha nem tesszük meg, akkor automatikusan a szülő osztályban implementált metódus fog lefutni.
330	330
331	331		### Absztrakt metódusok
332	332
333	333		Az automobilról mindenkinek ugyanaz a kép jut eszébe, azonban különböző gyártók különböző modelleket gyártanak, amelyek működésben is eltérhetnek egymástól. Úgy is fogalmazhatnánk, hogy attól még, hogy mi magunk is tudjuk, hogy nagyjából hogyan néz ki és működik egy autó, legyártani nem tudnánk. Tehát az automobilt egy absztrakt fogalomként kell értelmezni. Erre való az abstract kulcsszó használata:
334	334
335	335		``` pascal
336	336		type
337	337		TAutoMobil = class
338	338
339	339		{ Mezők: }
340	340
341	341		FSzin: String; { Az autó színe. }
342	342		FMaxSebesseg: Real; { Maximális sebesség. }
343	343		FMaxUtasok: Integer; { Utasok maximális száma. }
344	344		FAktualisSebesseg: Real; { Az aktuális sebesség. }
345	345		FAktualisUtasok: Integer; { A bent ülő utasok maximális száma. }
346	346		FAlvazSzam: String; { A gyárban beütött alvázszám. }
347	347		FMotor: TMotor; { Az autóba szerelt motor. }
348	348		FSebessegValto: TSebessegValto; { Az autóba szerelt sebességváltó. }
349	349
350	350		{ Metódusok: }
351	351
352	352		constructor Create(aSzin: String; aMaxSebesseg: Real; aMaxUtasok: Integer; aMotor: TMotor; aSebessegValto: TSebessegValto); virtual; abstract;
353	353		destructor Destroy; virtual; abstract;
354	354		procedure Gyorsit; virtual; abstract;
355	355		procedure Lassit; virtual; abstract;
356	356		procedure SetMotor(aMotor: TMotor); virtual; abstract;
357	357		procedure SetSebessegValto(aSebessegValto: TSebessegValto); virtual; abstract;
358	358
359	359		{ Tulajdonságok: }
360	360
361	361		property AlvazSzam: String read FAlvazSzam; { Csak olvasható tulajdonság. }
362	362		property Motor: TMotor read FMotor write SetMotor; { Olvasható és írható tulajdonság. }
363	363		property SebessegValto: TSebessegValto read FSebessegValto write SetSebessegValto;
364	364		end;
365	365		```
366	366
367	367		Erre a célra azonban megfelelőbb az interfészek használata.
368	368
369	369		### Öröklődés
370	370
371	371		A gyártók azonban a birtokában vannak az absztrakt fogalmak mögött rejlő tudásnak, ezért a saját elképzeléseik és tudásuk hozzáadásával egyedi automobilokat hoznak létre. Ezt nevezzük öröklődésnek (inheritance). Ennek megértéséhez be kell vezetnünk a szülő (parent) és gyerek (child) fogalmakat. Ez programozási szempontból a következőképpen néz ki, ha pl. a Mercedes gyárról beszélünk:
372	372
373	373		``` pascal
374	374		type
375	375		TMercedesAutoMobil = class(TAutoMobil)
376	376
377	377		FLegzsakokSzama: Integer;
378	378
379	379		procedure Gyorsit; override;
380	380		procedure Lassit; override;
381	381		end;
382	382		```
383	383
384	384		A class kulcsszó utáni zárójelben adjuk meg a szülő osztály nevét. Tehát a szülő osztály a TAutoMobil, a gyerek pedig a TMercedesAutoMobil lesz, amely örökölni fogja a szülő mezőit, metódusait és tulajdonságait. Ebben az esetben a Mercedes gyárnak kell meghatározni (programozási szempontból kifejteni) az abstract kulcsszóval ellátott metódusokat. Ehhez a deklarációs részben a metódusok után az override kulcsszót kell használni. Az absztrakt metódusok kifejtése mellett további mezők is kerülnek a gyerek objektumba, pl. a légzsákok száma - ami ugye nem feltétlenül része egy autónak (gondoljunk a régebbi modellekre). Ez az eljárás magával hozza azt a kérdést is, hogy mégis milyen tulajdonságokat, metódusokat örököljön majd a gyerek? Hogyan lehetne ezt definiálni? Erre valók a láthatóságot (visibility) definiáló kulcsszavak.
385	385
386	386		Folytatás hamarosan...
387	387
388	388		## Free Pascal Language Extensions
389	389
390	390		FPC includes several language extensions to its "standard" Pascal syntax to support object oriented programming.
391	391
392	392		- Objects (chapter 5) [[Programming Using Objects]]
393	393		- Classes (chapter 6) [[Programming Using Classes]]
394	394		- Interfaces (chapter 7) [[Programming Using Interfaces]]
395	395		- Generics (chapter 8) [[Programming Using Generics]]
396	396
397	397		These extensions are described in the indicated chapters of the FPC Language Reference Guide: <http://www.freepascal.org/docs.var>. Links to tutorial pages for each concept are included above as well. The Language Reference Guide includes syntax diagrams and further details not contained in this introductory tutorial. Of the four language features listed above, Objects and Classes form the basis of object oriented programming (OOP) in FPC and Lazarus. For those new to OOP, the Objects section includes more introductory concepts and the Classes section minimizes repetition by emphasizing the similarities and differences to the Objects syntax. In general, the Classes implementation seems to be more widely in use including Delphi Lazarus developers. Often the word "objects" is used to refer to what is actually a "class" in the Classes dialect of OOP in FPC. These documents will be worded to minimize any terminology confusion, but outside of this document, the term "object" oftentimes refers to objects created from a Class. In fact, the FPC run time library (RTL) includes a class library with a base class called TObject.
398	398
399	399		Users familiar with the older Turbo Pascal OOP implementation may initially want to skip the section on Classes since the Objects implementation is based on the older Turbo Pascal dialect. The section on Classes should be familiar to Delphi users since it is based on Delphi syntax. Be aware that some of the writeup in the Classes section may refer to concepts from the Objects section. For Macintosh developers familiar with the various Apple, THINK and MPW Object Pascal dialects, neither the FPC Objects or Classes dialects provide a direct migration path. As of March 2009, there are discussions on the Mac Pascal Mailing list about potentially providing some compiler support (new syntax) for accessing Apple's Objective C / Cocoa framework.
400	400
401	401		### General Concepts of Object Oriented Pascal
402	402
403	403		OOP provides different ways to manage and encapsulate data and to manage program flow compared with other available programming language features and constructs. OOP often lends itself to modeling certain applications such as Graphic User Interfaces (GUI's) and physical systems in a more natural feeling manner. However OOP is not appropriate for all applications. Program control is not as explicit as the more basic Pascal procedural constructs. To obtain the most benefit from OOP, understanding of large class libraries is often required which can entail a steep learning curve. Maintaining large OOP application code has its advantages and disadvantages compared to maintaining strictly procedural code. There are many sources for learning OO analysis, design and programming techniques which are beyond the scope of this guide.
404	404
405	405		There are numerous programming languages which incorporate OOP features as extensions or the basis of their language. As such, there are many different terms for describing OO concepts. Even within FPC, some of the terminology overlaps. In general, OOP usually consists of the concept of a programming object (or information unit) which explicitly combines and encapsulates a related set of data and procedures which act on the data. This data is usually persistent during program execution but with mechanisms to reduce some of the problems inherent in declaring global variables. In addition, OOP languages enable objects to be incrementally modified and/or extended based on previously defined objects. This feature is usually referred to by the terms inheritance and polymorphism. Many OOP languages use the terms method or message referring to procedures which belong to an object. Much of the power of OOP is realized by late (run time) dynamic binding of methods rather than compile binding. This dynamic binding of methods is similar to using procedural variables and procedural parameters but with greater syntactic cohesion, encapsulation with the data it is related to and also inheritance of behavior of previously defined methods. The following wiki pages provide a starting point for discovering more about analysis, design and programming in an object orient manner.
406	406
407	407		## Further information
408	408
409	409		This has only scratched the surface of the topic. For more details, readers are strongly recommended to read the [Free Pascal](http://lazarus-ccr.sourceforge.net/fpcdoc/ref/ref.html) manuals, especially Chapters 5 (Objects) and 6 (Classes)
410	410
411	411		## See Also
412	412
413	413		- [[Console Mode Pascal]]
414	414
415	415		## External Links
416	416
417	417		- <http://en.wikipedia.org/wiki/Object-oriented_programming>
418	418		- <http://en.wikipedia.org/wiki/OOAD>
419	419		- <http://en.wikipedia.org/wiki/Object_oriented_design>
420	420
421	421		---
422	422		From the Free Pascal wiki, page "Object Oriented Programming with Free Pascal and Lazarus/hu", as it stood on 2020-02-21 after a change by Trev, out of the wiki's dump of 2024-05-26. Copyright stays with the author who wrote it, according to the old wiki's [[Licensing]] page. If you have concerns about this material, [message the admin](/wiki-contact).

Back to history