Tegyük fel, hogy egy családot akarunk modellezni, és ehhez létrehozzuk az apa, anya, gyerek és unoka objektumokhoz a Father, Mother, Child és GrandChild osztályokat. Ezek az osztályok öröklési kapcsolatban vannak: a Child osztálynak mind a Father, mind a Mother osztály szülőosztálya, a GrandChild osztály pedig a Child osztályból örököl.

A Father és Mother osztályok az adott feladathoz és modellhez illeszkedő, az apára és anyára jellemző metódusokat tartalmaznak. A példa kedvéért legyen a Father osztályban csak két metódus: a mow_lawn() és az open_the_safe(). Az előbbivel az apát fűnyírásra tudjuk kérni, amit az apa a maga módján, a saját stílusában fog végrehajtani. Az utóbbi metódus egy széf nyitását valósítja meg. Ugyanis az apa a saját megtakarításait egy széfben tárolja, amit csak adott számok adott sorrendben történő bevitelével lehet kinyitni.

A Mother osztályban szintén két metódust definiálunk. Az egyik a cook(), ami az anya kiváló főzési képességét valósítja meg. A másik a make_herbal_tea(), merthogy az anya képes egy különleges, gyógyító hatású teát készíteni.

A Child és GrandChild osztályok e metódusokat öröklik. A kérdés az, hogy ezek közül melyiket logikus, célszerű vagy szabad felülírniuk?

A fűnyírás mikéntjére vonatkozóan a gyerek és unoka dönthet úgy, hogy megfigyeli az apát és pontosan ugyanúgy fogja végezni a fű lenyírását mint az apa. Ez azonban nem gyakori eset, hanem inkább az jellemző, hogy a gyerekek és unokák a saját egyéni módjukon nyírják a füvet, ami nem zárja ki, hogy a szülő technikáit is felhasználják. Tehát a mow_lawn() metódus felülírása a Child és GrandChild osztályokban logikus lehet.

Még inkább ez a helyzet az cook() metódussal. Az utódok bár alkalmazhatják a szülők vagy nagyszülők főzési fortélyait, de jellemzően a saját stílusukban fognak főzni. Ezért tehát a cook() metódus felülírása a Child és GrandChild osztályokban szinte természetes.

De mi a helyzet a páncélszekrény kinyitásával? Mivel ez csak egy adott számkombináció megfelelő sorrendben történő megadásával tehető meg, ezért az utódoknak az open_the_safe() metódust nem szabad (de legalábbis nem célszerű) felülírni, mert akkor a széf nem nyitható. Ugyanez igaz a gyógytea készítésére. A kívánt hatás ugyanis csak akkor jelentkezik, ha adott gyógynövények meghatározott arányban vannak jelen a keverékben. Ha az összetevők aránya ettől eltér, vagy akár csak egy is hiányzik, akkor a gyógyhatás nem érvényesül. Tehát a make_herbal_tea() metódust nem szabad felülírni a Mother semelyik alosztályában, mert akkor a meghívás után nem a várt eredményt kapják az utódok.

Most, hogy a Father és Mother osztályokban azonosítottunk olyan metódusokat, amelyek alosztályokban történő felülírása nem kívánatos, a kérdés az, hogy hogyan jelezzük ezt az osztályok felhasználói számára.

Nos, erre szolgál a szabványos könyvtár typing moduljának final nevű függvénye. A nem felülírható metódust ezzel kell dekorálni. Ezt mutatjuk alább:

Ha ezt megtesszük, akkor nem csak a felhasználók tudják beazonosítani a nem felülírható metódusokat, hanem a statikus típusellenőrző alkalmazások is. Ezek hibajelzést fognak adni, ha találnak olyan alosztályt, amely felülír egy final dekorátorral ellátott metódust.

A final dekorátor hasznos, de nem kényszeríti ki futási időben a felülírhatatlanság követelményét. Vagyis, ha egy alosztály mégis felülír egy final metódust, akkor a kód akár hiba nélkül is lefuthat, és a szemantikai gond csak akkor fog kiderülni, ha a metódus az alosztály példányán meg lesz hívva.

Jó lenne valahogy elérni, hogy a nem megengedett felülírás futási időben idejekorán észlelhető legyen.

A Python 3.11-tól ez megvalósítható. Ugyanis ettől a verziótól a final dekorátor a dekorált metódusobjektumon létrehozza a __final__ speciális metódust, amit True értékre be is állít. Ez nem azt jelenti, hogy a final dekorátorral nem érintett metódusobjektumoknak is lesz __final__ attribútumuk és az False értékű. Nem, ezek a metódusobjektumok változatlanok maradnak.

Azt tudjuk tehát, hogy minden final dekorátorral ellátott metódusnak lesz egy __final__ speciális attribútuma. Ennek alapján össze tudjuk szedni egy adott osztály azon metódusneveit, amelyeket nem szabad alosztályban felülírni. Ha futási időben az alaposztályban valamilyen automatizmussal össze tudnánk gyűjteni az alosztályban definiált metódusneveket is, akkor ezeket összevetve az előbbi nevekkel meg lehetne tudni, hogy történt-e tiltott felülírás vagy sem. Ha igen, akkor kivételdobással lehetne ezt jelezni. A kérdés, hogy van-e olyan automatizmus, ami az alaposztályban rendelkezésre bocsátja az alosztályok metódusait vagy magát az alosztályobjektumot.

Igen, van ilyen lehetőség, ha az alaposztályban definiáljuk az __init_subclass__(cls) metódust. E metódus automatikusan meghívódik, valahányszor az adott osztályból újabb alosztályt hozunk létre. A cls nevű paraméter az új alosztályra fog hivatkozni, azaz az __init_subclass__ metódus törzsében rendelkezésre áll az alosztályobjektum. Ennek ismeretében az alábbiakat fogjuk tenni:

1. Egy halmazban összegyűjtjük az alaposztályok azon metódusainak neveit, amelyek nem felülírhatónak vannak megjelölve, azaz a typing modul final függvényével vannak dekorálva.
2. Ezt úgy tesszük, hogy végighaladunk az alosztály öröklési láncában szereplő összes osztályon, és azok attribútumai közül kiválogatjuk azon metódusokat, amelyek rendelkeznek a __final__ attribútummal.
3. Egy halmazban összegyűjtjük az alosztályban definiált metódusok neveit.
4. Képezzük a nem felülírhatónak megjelölt és az alosztályban definiált metódusok metszetét.
5. Ha nincs tiltott felülírás, akkor ez egy üres halmaz lesz. Ha viszont nem az, akkor a halmaz elemei azon metódusnevek, amelyeket az adott alosztály felülírt. Ekkor egy kivétel dobunk felsorolva, hogy mely metódusok lettek felülírva.

Ezt láthatjuk alább kódban, ahol a fenti lépéseknek megfelelő kódsorok a Father osztályban kommentekkel beazonosíthatók. Mivel a Mother osztályban is ugyanez a kód szerepel, ezért ott a kommentek nem jelennek meg.

A működés teszteléséhez a GrandChild osztályban szándékosan felülírtuk a make_herbal_tea() metódust. Ha lefuttajuk az osztálydefiníciókat tartalmazó szkriptet, akkor FinalMethodOverrideError kivétel keletkezik, amelynek hibaüzenete megmondja, hogy mely alosztály mely nem felülírható metódusokat írta felül.

Mondhatnánk, hogy készen vagyunk, hiszen van egy működőképes mechanizmusunk a tiltott felülírások futási időben, de még a definíciós fázisban történő kiszűrésére. De, ahogy látjuk minden alaposztályban ugyanazt az ellenőrző kódsort meg kell ismételni. Mint tudjuk, a forráskód másolással történő ismétlése karbantartási nehézséget okoz és hibalehetőséget hordoz. Ezért ismétlődő forráskód esetén meg kell vizsgálni, hogy lehet-e és hogyan kiemelni az ismétlődő kódsorokat úgy, hogy azokat csak egyszer kelljen megírni.

Jelen esetben igen, ki lehet szervezni az ismétlődő __init_subclass__ metódust mégpedig egy mixin osztályba. Ha így teszünk, akkor minden olyan alaposztályban, amely final metódust tartalmaz és örökli a mixin osztályt, az alosztályban történő felülírás ellenőrzésre kerül. Így egy rugalmas osztálystruktúrát kapunk, amely a következő:

Ebben a bejegyzésben elsősorban a typing modul final dekorátorát, az egyszeres és többszörös öröklést, az egyéni kivételek definiálását és a mixin osztályokat érintettük. Ezekről a Python tudásépítés lépésről lépésre című e-könyvben a „Típusutalások és statikus típusellenőrzés támogatása”, „Öröklődés” és „Egyéni kivételtípusok megvalósítása” című fejezetekben lehet részletesen olvasni.