A c# nyelvben hogyan lehetne megfogalmazni elképzelhetőbb formában a system. Object-et "ősosztályt"?

A származtatás valóban azt jelenti, hogy a származtatott (másolt) objektum hordozza a szülőobjektum tulajdonságait, de azok ezen a példányon már módosíthatók, akár tovább is örökíthetők. De a példány tulajdonságainak módosítása nem hat vissza a szülőobjektumra, vagyis abból több másik, "érintetlen" példány is származtatható. Az objektum is csak egy összetett adatsor, ezért a származtatás azt jelenti, hogy létrehozunk róla egy másolatot, és azon változtathatunk is.

A System.Object olyan, mintha a klónozáshoz vennénk egy vonások nélküli "ember-alapot", ami csak olyan, mint egy egyszerű rajz. Azért kell egy ilyen, hogy az "objektum", mint típus, egyáltalán bevezethető legyen. Ez csak a programnyelv elvi trükközése, az a célja, hogy egy következetes logikai építkezésnek adjon egy szilárd pontot.

Amikor OOP-ban programozol, akkor a programodat úgy képzeld el, mint egy világot.

Azért írunk programokat, hogy helyettünk megoldjon valamilyen problémát, vagy ha nem is tudja teljes mértékben megoldani, de segítsen bennünket. Ha belegondolsz, a program a mi világunkban fellelhető dolgok tulajdonságait és viselkedéseit használja fel. A célunk az lesz, hogy a mi világunkban található dolgok valamilyen úton-módon bekerüljenek a programunk világába.

Amikor egy rendszert készítesz, vannak olyan dolgok, amik lényegesek a rendszer szempontjából, és vannak olyan dolgok, amik nem lényegesek. Ezért fogunk modellezni. A modellezés első lépése során kiválogatjuk a mi világunkból a rendszer számára fontos dolgokat. Ugyanakkor egy, az első lépés során kiválasztott dolognak is vannak olyan tulajdonságai és viselkedései, amik a rendszer számára fontosak, míg a többiek nem. A modellezés második lépésében tehát csak a rendszer számára fontos tulajdonságokat és viselkedéseket hagyjuk meg.

Erre egy példa:

Akarsz csinálni egy pizzarendelő rendszert. A mi világunk tartalmaz ugye pizzériákat, embereket, különféle felvágottakat, zöldségeket, tésztát, sajtot, szószokat, kocsmákat, iskolákat, parafatáblákat, szekrényeket, stb. Azért egy pizzarendelő rendszer számára ezek közül nem mind szükséges. Ami fontos lesz:

- a pizzéria

- az ember

- a felvágott

- a zöldség

- a szósz

- a tészta

De kétlem, hogy a pizzarendelő rendszer szempontjából fontosak lennének a szekrények.

De miután ez megvan, az egyes dolgoknak, mint például pizzériáknak is vannak olyan tulajdonságai, amik a rendszer számára fontosak, és amelyek nem. Minket érdekelni fog:

- a címe

- a telefonszáma

- a nyitvatartási ideje

- a kiszállítási idő

- milyen pizzái vannak

De rohadtul nem érdekel, hogy a pizzériának hány ablaka van és milyen téglából építették.

Kell valami eszköz, amivel a mi világunk dolgairól készített modelleket át tudjuk vinni az OOP programunk világába. Ez lesz az osztály. Az osztály nem más, mint egy kis leírás arról, hogy annak a valaminek miket kell tudnia és csinálnia. Szóval ez olyan, mint egy papírlap, egy terv. De ez még nem a konkrétan létező tárgy. Ahhoz, hogy megkapjuk a ténylegesen használható tárgyat, azaz az objektumot vagy példányt, példányosítani kell azt. De ebbe nem mennék jobban bele, mert ez irreleváns.

Van egy olyan dolog, hogy öröklődés. Tegyük fel, rájössz arra, hogy te csináltál olyan dolgokat, amik között észrevehető valami kapcsolat, és ebből kifolyólag vannak olyan tulajdonságai és viselkedései, amik egyaránt megtalálhatóak mindegyikben.

Például te csinálsz:

- éttermet

- pizzériát

- gyros bárt

stb. Ha észreveszed, ezekben mindben lehet kaját venni, van címük, telefonszámuk, lehet tőlük rendelni, stb. Lényegében ezek étkezdék. Akkor miért ne emelnéd ki a közös dolgokat egy Étkezde osztályba, és mondanád meg, hogy az Étterem, Pizzéria és a GyrosBár mind ennek az Étkezdének legyen a leszármazottja? Így elég egyszer leírnod és ott lesz mindegyikben. De ez magával hoz egy nagyon fontos viselkedést, a polimorfizmust. Ha tudom, hogy az Étterem, a Pizzéria és a GyrosBár mind Étkezdék, akkor miért ne kezelhetném őket Étkezdeként?

Étkezde a = new Étterem();

Étkezde b = new Pizzéria();

Étkezde c = new GyrosBár();

Viszont ha megnézed, így mindhárom csak azokat a tulajdonságokat és viselkedéseket tudja, amit az Étkezde tud. Ez azért van, mert egy Étkezde nem minden esetben tud mindent, amit egy Étterem, Pizzéria vagy GyrosBár. Ez azért van, mert van olyan, hogy:

- statikus típus

- dinamikus típus.

Az első nagyon röviden azt jelenti, hogy milyen típusú a kifejezésed vagy a változód. Jelen példában a statikus típus az Étkezde. A dinamikus típus azt jelenti, hogy mi az a dolog valójában (például az "a" dinamikus típusa Étterem).

Ezért teheted ezt meg:

Étkezde a = new Étterem();

Étterem e = (Étterem) a;

De ez már nem fog működni:

Étkezde a = new Étterem();

Pizzéria p = (Pizzéria) a; //az "a" dinamikus típusa nem Pizzéria, hanem Étterem.

Na de minket a System.Object érdekel. Azért, hogy egy dolog "helyt álljon" az OOP világban, tudnia kell bizonyos dolgokat, például:

- tudnia kell információt adni önmagáról (GetType)

- tudnia kell az állapotát System.String-ként leírni (ToString)

- el kell tudnia dönteni, hogy az állapota (azaz a tulajdonságainak értékei) alapján megegyezik-e egy másik System.Object-tel (Equals)

- tudnia kell a tulajdonságai alapján egy hash kódot előállítani (GetHashCode)

meg még van benne egy pár apróság.

És ezeket jó lenne, ha nem a nulláról kellene nekünk megírni. Ezért van az, hogy minden osztály, amit csinálunk, ebből a System.Object-ből származik.