Hogyan magyarázzuk el az objektum-orientált programozási koncepciókat egy 6 éves gyereknek

Észrevette, hogy az állásinterjúkon mindig ugyanazokat a közhelyes kérdéseket teszik fel - újra és újra?

Biztos vagyok benne, hogy tudja, mire gondolok.

Például:

Hol látja magát öt év múlva?

vagy ami még rosszabb:

Mit tart a legnagyobb gyengeségének?

Ugh ... adj egy kis szünetet. A kérdés megválaszolását nagy gyengeségnek tartom! Egyébként nem az én véleményem.

Bármennyire is triviálisak az ilyen kérdések, ezek azért fontosak, mert nyomokat adnak rólad. Jelenlegi lelkiállapotod, hozzáállásod, perspektívád.

A válaszadáskor körültekintőnek kell lennie, mivel felfedhet valamit, amit később megbán.

Ma hasonló típusú kérdésekről szeretnék beszélni a programozási világban:

Melyek az objektumorientált programozás fő elvei?

A kérdés mindkét oldalán álltam. Ez egyike azoknak a témáknak, amelyeket olyan gyakran feltesznek, hogy nem engedheti meg magának, hogy ne ismerje.

A junior és belépő szintű fejlesztőknek általában meg kell válaszolniuk. Mivel az interjúztatónak három dolga van:

  1. Felkészült a jelölt erre az interjúra?

    Bónuszpontok, ha azonnal hallasz választ - ez komoly megközelítést mutat.

  2. A jelölt túl van az oktató szakaszon?

    Az objektumorientált programozás (OOP) elveinek megértése azt mutatja, hogy túllépett a másoláson és az oktatóanyagok beillesztésén - máris magasabb perspektívából látja a dolgokat.

  3. Mély vagy sekély a jelölt megértése?

    A kérdés kompetenciaszintje gyakran megegyezik a legtöbb tantárgy kompetenciaszintjével . Bízz bennem.

Az objektum-orientált programozás négy alapelve a kapszulázás , absztrakció , öröklés ,és a polimorfizmus .

Ezek a szavak ijesztően hangozhatnak egy junior fejlesztő számára. A Wikipedia bonyolult, túl hosszú magyarázatai pedig néha megduplázzák a zavart.

Ezért szeretnék egyszerű, rövid és világos magyarázatot adni ezekre a fogalmakra. Lehet, hogy úgy hangzik, mintha elmagyaráznád egy gyereknek, de én nagyon szívesen hallanám ezeket a válaszokat, amikor interjút folytatok.

Egységbezárás

Mondjuk, hogy van programunk. Van néhány logikailag különböző objektuma, amelyek kommunikálnak egymással - a programban meghatározott szabályok szerint.

A beágyazás akkor valósul meg, amikor minden objektum magánállapotban tartja az osztályt. Más objektumok nem rendelkeznek közvetlen hozzáféréssel ehhez az állapothoz. Ehelyett csak a nyilvános funkciók listáját hívhatják - úgynevezett módszereket.

Tehát az objektum saját módszerét kezeli metódusokkal - és egyetlen más osztály sem érheti meg, hacsak kifejezetten nem engedélyezik. Ha kommunikálni akar az objektummal, használja a megadott módszereket. De (alapértelmezés szerint) nem változtathatja meg az állapotot.

Tegyük fel, hogy egy apró Sims játékot építünk. Vannak emberek és van macska. Kommunikálnak egymással. Kapszulázást akarunk alkalmazni, ezért az összes „macska” logikát aCatosztály. Így nézhet ki:

Itt a macska „állapota” a privát változókmood , hungryés energy. Van privát módszere is meow(). Akkor hívhatja, amikor csak akarja, a többi osztály nem tudja megmondani a macskának, hogy mikor kell nyávogni.

Amit megtehetnek, azt a nyilvános módszerek határozzák meg sleep(), play()és feed(). Mindegyikük valahogy módosítja a belső állapotot, és hivatkozhat rá meow(). Így létrejön a kötés a magánállam és az állami módszerek között.

Ez beágyazás.

Absztrakció

Az absztrakció a kapszulázás természetes kiterjesztésének tekinthető.

Az objektum-orientált tervezésnél a programok gyakran rendkívül nagyok. A különálló tárgyak pedig sokat kommunikálnak egymással. Tehát egy ilyen nagy kódbázis fenntartása évekig - változásokkal együtt - nehéz.

Az absztrakció olyan koncepció, amelynek célja a probléma enyhítése.

Az absztrakció alkalmazása azt jelenti, hogy minden objektumnak csak egy magas szintű mechanizmust szabad kitennie annak használatára.

Ennek a mechanizmusnak el kell rejtenie a belső megvalósítás részleteit. Csak a többi objektum szempontjából releváns műveleteket szabad felfednie.

Gondolj - egy kávéfőző. Sok mindent csinál, és furcsa hangokat ad a motorháztető alatt. Csak annyit kell tennie, hogy betesz egy kávét, és megnyom egy gombot.

Ennek a mechanizmusnak előnyösen könnyen használhatónak kell lennie, és ritkán változhat az idő múlásával. Gondoljon arra, mint egy kis nyilvános módszerre, amelyet bármely más osztály hívhat anélkül, hogy tudná, hogyan működik.

Az absztrakció másik valós példája?

Gondoljon arra, hogyan használja a telefont:

Csak néhány gomb használatával léphet kapcsolatba telefonjával. Mi történik a motorháztető alatt? Nem kell tudnia - a megvalósítás részletei rejtve vannak. Csak rövid műveleteket kell ismernie.

A megvalósítás módosításai - például egy szoftverfrissítés - ritkán befolyásolják a használt absztrakciót.

Öröklés

Rendben, láttuk, hogy a kapszulázás és az absztrakció hogyan segíthet nekünk egy nagy kódbázis fejlesztésében és fenntartásában.

De tudod, mi a másik általános probléma az OOP tervezésében?

A tárgyak gyakran nagyon hasonlóak. Közös logikájuk van. De nem teljesen egyformák. Ugh…

Tehát hogyan használhatjuk fel újra a közös logikát, és hogyan vonhatjuk ki az egyedi logikát egy külön osztályba? Ennek egyik módja az öröklés.

Ez azt jelenti, hogy egy (gyermek) osztályt úgy hoz létre, hogy egy másik (szülő) osztályból származik. Így hierarchiát alkotunk.

A gyermekosztály újrafelhasználja a szülőosztály összes mezőjét és módszerét (közös rész), és megvalósíthatja a sajátját (egyedi része).

Például:

Ha programunknak az állami és magántanárok, de más típusú emberek, például a hallgatók kezelésére van szüksége, akkor ezt az osztályhierarchiát megvalósíthatjuk.

Így minden osztály csak annyit ad hozzá, ami szükséges hozzá, miközben újból felhasználja a közös logikát a szülő osztályokkal.

Polimorfizmus

A legösszetettebb szóhoz értünk! A polimorfizmus görögül „sok alakot” jelent.

Tehát már ismerjük az öröklés erejét és boldogan használjuk. De jön ez a probléma.

Tegyük fel, hogy van szülő osztályunk és néhány gyermekosztályunk, amelyek örökölnek belőle. Néha olyan gyűjteményt szeretnénk használni - például egy listát -, amely ezeknek az osztályoknak a keverékét tartalmazza. Vagy van egy módszerünk a szülői osztály számára - de szeretnénk használni a gyermekek számára is.

Ez megoldható polimorfizmus alkalmazásával.

Egyszerűen fogalmazva: a polimorfizmus módot ad arra, hogy egy osztályt pontosan úgy használjunk, mint a szülője, így nincs összetévesztés a keverési típusokkal.De minden gyermekosztály megtartja a maga módszereit.

Ez általában egy újból felhasználandó (szülő) felület definiálásával történik. Egy csomó általános módszert vázol fel. Ezután minden gyermekosztály megvalósítja a módszerek saját verzióját.

Bármikor, amikor egy gyűjtemény (például egy lista) vagy egy módszer elvárja a szülő egy példányát (ahol közös módszerek vannak felvázolva), a nyelv gondoskodik a közös módszer helyes megvalósításának értékeléséről - függetlenül attól, hogy melyik gyermeket adták át.

Vessen egy pillantást a geometriai ábrák megvalósításának vázlatára. Újra felhasználják a felületet és a kerület kiszámításához használt közös interfészt:

Miután ezek a három alak örökli a szülő Figure Interfacesegítségével hozzon létre egy listát a vegyes triangles, circlesés rectangles. És úgy bánj velük, mint ugyanazon típusú tárgyakkal.

Ezután, ha ez a lista megkísérli kiszámolni egy elem felületét, akkor megtalálja és végrehajtja a helyes módszert. Ha az elem háromszög, akkor háromszögCalculateSurface()nak, nek hívják. Ha ez egy kör - akkor cirlce-éCalculateSurface()nak, nek hívják. Stb.

Ha van olyan függvénye, amely egy ábrával a paraméterének használatával működik, akkor nem kell háromszor definiálnia - egyszer háromszög, kör és téglalap esetén.

Megadhatja egyszer, és elfogadhatja a Figureérvként. Akár elhalad egy háromszög, kör vagy téglalap mellett - amíg megvalósulnak CalculateParamter(), a típusuk nem számít.

Remélem, ez segített. Ezeket a magyarázatokat közvetlenül felhasználhatja az állásinterjúkon is.

Ha valami még mindig nehezen érthető dolog - ne habozzon, kérdezze meg az alábbi megjegyzésekben.

Mi a következő lépés?

Nagyszerű felkészülni arra, hogy megválaszolja az interjúk egyik klasszikus kérdését - de néha soha nem hívják interjúra.

Ezután arra fogok összpontosítani, hogy mit akarnak látni a munkaadók egy junior fejlesztőben, és hogyan lehet kitűnni a tömegből az álláskeresés során.

Maradjon velünk.