A Delphi megjegyzi a delphi sablonokat (de nem általános)

A saját szavamban fogok írni, remélem olyan formában, amely hozzáférhető a tömegolvasó számára.

Tehát feltételezzük, hogy van pár osztályunk: TSomeType1 és TSomeType2. amelyek a SomeUnit.pas-ban jelentek meg. És feltételezzük, hogy ezek az osztályok ugyanazokat a tulajdonságokat és módszereket tartalmazzák, de ezek a tulajdonságok és módszerek nem szerepelnek a közös ősökben. Például legyen:

Itt látjuk a DoSomething módszert. amely mindkét osztályban van. De ezek két különböző módszer.

Tipp: És tegyük fel, hogy nincs lehetőségünk módosítani a SomeUnit.pas-ot. Ez fontos annak megértéséhez, hogy miért írtam le ezt a megközelítést.

És most mondjuk, hogy van egy feladatunk. írj egy olyan osztályt, amely az osztályaink példányain fog működni, és felhívja nekik DoSomething (egyes eseményekhez). És azóta A TSomeType1 és a TSomeType2 különböző osztályok, ezért két új osztályt kell írni. T1-nek és T2-nek nevezzük. Hogyan lehet ezt tenni? Nos, például a homlokán (MyUnit.pas fájl):

TIPP: Itt a DoSomething hívás csak egyszer fordul elő a T1 és T2 osztályok konstruktorában. Ez egyáltalán nem praktikus, de ez csak egy példa, amelyen a bemutatott technikát szeretném bemutatni.

Használja valahol a következő kóddal:

Most képzeljük el, hogy a T1 és T2 osztályaink sokkal több munkát végeznek. Ie kód lesz. De így a kód egybeesik. A kód duplikálódik. Hogyan lehet elkerülni?

Gondoltam először - általánosságban

Próbáljunk általánosságokat. ezek szintén generikusok. A MyUnit.pas mi így fog kinézni:

De sajnos ez a kód nem fordul elő. Mivel a FObject.DoSomething sorozatot össze kell állítani, tudnia kell, hogy a DoSomething módszer T. típusú, és a fordító egyszerűen nem tudja tudni. És nem találtam módot arra, hogy bármilyen módon meghatározzam. Meghatározható, hogy melyik osztályt kell elnyerni a T. típustól, vagy melyik T típusú interfésznek kell támogatnia. De a mi példánkban ez nem megfelelő (nem tudunk szerkesztést végrehajtani a SomeUnit.pas-ban, emlékszel?).

A második gond a kód sablonok

Ezt a kódot kétszer kell helyettesíteni. De egy fájlban ez nem hajtható végre, ezért két kiegészítő fájlt hozunk létre.

TIPP: Ha nem érted pontosan, mi folyik itt, helyettesítsd az X.inc fájlt az A.pas és a B.pas fájlok között az irányelv helyett. És látni fogod, hogy két teljes modul van.

TANULÁS: Szigorúan megfogalmazva, nem próbáltuk elkerülni a végrehajtható kód megismétlődését (mint a generikumok esetében). Amikor összeállítjuk a példát, az inc-fájl kétszer helyettesíthető. De sikerült elkerülni a párhuzamosítást a forráskód szinten - és ez időnként sokat ér.

Ezután a MyUnit.pas modulunkat újra kell írni, ez lesz az:

És azt is használhatjuk, mint fent.

Miért van ez szükség

Abban az esetben, ha nem lehetséges a SomeUnit.pas típusú forrásmodul módosítása. ilyen technika lehet az egyetlen, amely lehetővé teszi hasonló problémák megoldását.

Például a VCL-ben van egy TCombobox komponens. A Style = csSimple vagy Style = csDropdown módban normális TEdit-ként működik. Mind a TCombobox, mind a TEdit hasonló tulajdonságokkal rendelkezik: MaxLength. SelStart. SelLength. SelText stb. Ezeket a tulajdonságokat azonban nem a közös õseiként (TWinControl), hanem a TCustomComboBox és a TCustomEdit osztályokban deklarálják.

Az előző cikkben azt írtam le, hogyan változtathatsz kissé a MaxLength tulajdonság standard viselkedését a TCustomEdit örököseire (pl. TEdit, TMemo stb.). És ahhoz, hogy képes legyen alkalmazni a TCustomComboBox-ra - a fent leírt technikát alkalmazzuk.

A Delphi megjegyzi a delphi sablonokat (de nem általános)

Előnyei és hátrányai ennek a technikának

  • Mi megoldottunk egy bizonyos problémát, amikor nincs lehetőség (vagy nincs vágy), hogy módosítsunk egy külső könyvtár forráskódját.
  • Kerüljük a duplikált kódot.
  • Amikor a kódot egy inc fájlba helyezzük, akkor szükségünk van egy kicsit több képzelőerőre, mint a szokásos: gondold meg a fájlok nevét és cserélhető típusokat, és képzeljük el, hogyan fog kinézni a végén.
  • Az IDE, amely az inc-fájlokkal dolgozik, nem tudja előre, hogy melyik helyet foglalja ez az inc fájl. Ennek következtében a CodeInsight nem működik itt. Előfordulhat, hogy problémákat okoz a refactoring és az automatikus kód formázása.

És egy ilyen árnyalat. Az inc-fájlokkal ellátott hibakereső ugyanúgy működik, mint a rendszeres pas-fájlokkal. De (mint a generikumok esetében) az inc-fájlban töréspontot állít be, ez a pont mind a T1, mind pedig a T2 esetében szerepel. Megoldja a töréspont feltételeinek feltüntetésével, például: Az önálló T1.

Kapcsolódó cikkek