Objektumtípus (objektum-orientált programozás) - Object type (object-oriented programming)

A számítástechnikában az objektumtípus (más néven csomagolóobjektum ) olyan adattípus , amelyet az objektumorientált programozás során nem objektumtípus beburkolására használnak , hogy dinamikus objektumnak tűnjön .

Egyes objektum-orientált programozási nyelvek megkülönböztetik a referencia- és értéktípusokat , amelyeket gyakran objektumokként és nem objektumokként emlegetnek azokon a platformokon, ahol komplex értéktípusok nem léteznek, például futásidejű hatékonyság, szintaxis vagy szemantikai problémák miatt. Például Java van primitív wrapper osztályok mindegyikének megfelelő primitív típus : Integerés int, Characterés char, Floatés float, stb nyelvek, mint a C ++ alig vagy egyáltalán nem fogalma referencia típus ; így az objektumtípus használata kevéssé érdekes.

Boksz

A bokszolás, más néven csomagolás, egy primitív típus elhelyezése az objektumon belül, hogy a primitív referenciatárgyként használható legyen. Például a Java-ban az a LinkedListmegváltoztathatja a méretét, de egy tömbnek rögzítettnek kell lennie. Lehetséges, hogy van egy LinkedListof-ból int, de az LinkedListosztály csak a dinamikus objektumokra vonatkozó hivatkozásokat sorolja fel - nem sorolhat fel primitív típusokat, amelyek értéktípusok.

Ahhoz, hogy megkerüljék ezt, intlehet belebokszolt Integer, amelyek a dinamikus objektumokat, majd hozzáadjuk LinkedLista Integer. (A J2SE 5.0-ban bevezetett általános paraméterezett típusokat használva ez a típus a következőképpen jelenik meg .) Másrészt a C # -nak nincs primitív burkolóosztálya, de bármilyen értéktípusú bokszolást lehetővé tesz, és általános referenciát ad vissza. Az Objective-C- ben bármely primitív értéket előhívhat egy a-val, hogy ki lehessen belőle (pl. Vagy ). Ez lehetővé teszi azok hozzáadását bármelyik szabványos gyűjteménybe, például egy . LinkedList<Integer>Object@NSNumber@123@(123)NSArray

A dobozos objektum mindig az értékobjektum másolata, és általában megváltoztathatatlan . Az objektum kicsomagolásával a tárolt érték másolatát is visszaadja. Az objektumok ismételt bokszolása és kibontása súlyos teljesítményhatást gyakorolhat, mivel az ökölvívás dinamikusan osztja ki az új objektumokat, és az unboxing (ha a dobozos értéket már nem használják) jogosulttá teszi őket szemétgyűjtésre . Azonban a modern szemétgyűjtők, mint például az alapértelmezett Java HotSpot szemétgyűjtő, hatékonyabban képesek összegyűjteni a rövid élettartamú objektumokat, így ha a dobozos objektumok rövid élettartamúak, akkor a teljesítmény hatása nem lehet olyan rossz.

Egyes nyelvekben közvetlen egyenértékűség van egy doboz nélküli primitív típus és egy megváltoztathatatlan, dobozos objektumtípusra való hivatkozás között. Valójában lehetőség van a program összes primitív típusának helyettesítésére dobozos objektumtípusokkal. Míg az egyik primitívről a másikra történő hozzárendelés átmásolja annak értékét, az egyik referenciáról a dobozos objektumra a másikra történő hozzárendelés a referenciaértéket másolja, hogy ugyanarra az objektumra utaljon, mint az első referencia. Ez azonban nem fog problémát okozni, mert az objektumok megváltoztathatatlanok, tehát szemantikailag nincs valódi különbség két ugyanazon objektumra vagy más objektumra történő hivatkozás között (hacsak nem a fizikai egyenlőséget vizsgáljuk). A hozzárendelésen kívüli összes művelet, például számtani, összehasonlító és logikai operátorok esetén kipakolhatja a dobozos típust, elvégezheti a műveletet, és szükség szerint újra dobozolhatja az eredményt. Így lehetséges egyáltalán nem tárolni a primitív típusokat.

Autoboxolás

Az autoboxolás az a kifejezés, amellyel a referencia típus ki lehet jutni egy értéktípusból, csak típuskonverzióval (akár implicit, akár explicit). A fordító automatikusan megadja az objektumot létrehozó extra forráskódot.

Például a Java J2SE 5.0 előtti verzióiban a következő kód nem fordult le:

Integer i = new Integer(9);
Integer i = 9; // error in versions prior to 5.0!

Az 5.0 előtti fordítók nem fogadják el az utolsó sort. Integera referencia tárgy, a felszínen nem különbözik List, Objectés így tovább. Átalakítani egy intolyan Integer, az egyik volt a „kézzel” példányosítjuk az Egész objektum. A J2SE 5.0-tól kezdődően a fordító elfogadja az utolsó sort, és automatikusan átalakítja azt úgy, hogy létrejön egy Integer objektum az érték tárolására 9. Ez azt jelenti, hogy a J2SE 5.0-tól kezdve valami ilyesmi , ahol és hol vannak , most fognak összeállítani - az a és a b dobozolatlanok, az egész értékek összegződnek, és az eredményt egy újba mentik , amely végül a változóban tárolódik . Az egyenlőség operátorok nem használhatók így, mert az egyenlőség operátorok már meg vannak határozva a referencia típusokra, a referenciák egyenlőségére; az érték egyenlőségének teszteléséhez dobozos típusban, akkor is manuálisan kell kibontani őket, összehasonlítani a primitíveket, vagy használni kell a módszert. Integer c = a + babIntegerIntegercObjects.equals

Egy másik példa: A J2SE 5.0 lehetővé teszi a programozó számára, hogy egy gyűjteményt (például a LinkedList) úgy kezeljen , mintha objektumok inthelyett értékeket tartalmazna Integer. Ez nem mond ellent a fentieknek: a gyűjtemény továbbra is csak dinamikus objektumokra vonatkozik, és nem sorolhat primitív típusokat. Nem lehet a , de helyette kell lennie . A fordító azonban automatikusan átalakítja a kódot úgy, hogy a lista "némán" fogadja az objektumokat, míg a forráskód csak primitív értékeket említ. Például a programozó most írhat és úgy gondolkodhat, mintha a listához adták volna; de a fordító valóban átalakítja a sort . LinkedList<int>LinkedList<Integer>list.add(3)int 3list.add(new Integer(3))

Kicsomagolás

Az unboxing az adott objektumhoz társított érték megszerzésére utal, csak a típuskonverzió (implicit vagy explicit) révén. A fordító automatikusan szállítja az extra forráskódot, amely lekéri az értéket az objektumból, vagy valamilyen módszer meghívásával az objektumon, vagy más módon.

Például a Java J2SE 5.0 előtti verzióiban a következő kód nem fordult le:

Integer k = new Integer(4);
int l = k.intValue(); // always okay
int m = k;            // would have been an error, but okay now

A C # nem támogatja a Java-val megegyező értelemben vett automatikus kicsomagolást, mert nincs külön primitív és objektumtípus halmaza. Minden olyan típust, amelynek primitív és objektum verziója egyaránt van a Java-ban, a C # fordító automatikusan végrehajtja primitív (érték) vagy objektum (referencia) típusként.

Az automatikus ökölvívás mindkét nyelven nem áll le automatikusan, vagyis a következő kód nem áll össze:

C #:

int i = 42;
object o = i;         // box
int j = o;            // unbox (error)
Console.WriteLine(j); // unreachable line, author might have expected output "42"

Jáva:

int i = 42;
Object o = i;          // box
int j = o;             // unbox (error)
System.out.println(j); // unreachable line, author might have expected output "42"

Írja be a segítőket

A Modern Object Pascalnak van még egy módja egyszerű műveletek végrehajtására, a bokszhoz közel, úgynevezett típusú segítőknek a FreePascal-ban, vagy a rekord-segítőknek Delphi-ben és FreePascal -nak Delphi módban.
Az említett dialektusok az Object Pascal fordítás anyanyelvi nyelvek, ezért hiányolnak néhány olyan funkciót, amelyet a C # és a Java megvalósíthat. Különösen a futásidejű következtetés az erősen tipizált változókra.
De a funkció az ökölvívással kapcsolatos.
Ez lehetővé teszi a programozó számára, hogy hasonló konstrukciókat használjon

{$ifdef fpc}{$mode delphi}{$endif}
uses sysutils;  // this unit contains wraps for the simple types
var
  x:integer=100;
  s:string;
begin
  s:= x.ToString;
  writeln(s);
end.

Hivatkozások