O objektno-orijentisanom programiranju


Ovo je članak koji će pokušati da te na nepompezan način uvede u objektno-orijentisano programiranje - OOP.

Daleko bilo da je ovo sve što treba da znaš o toj temi. "Najbolji način da se započne put od 10000 kilometara je da se napravi prvi korak" - kineska poslovica (naravno original razdaljinu nije merio kilometrima). Shvati ovo upravo kao pokušaj da se taj prvi korak napravi što bezbolnije.

Pretpostavlja se da si programirao na Pascal-u, C-u ili nekom "običnom" procedurelnom jeziku i da si osetio da ti nešto nedostaje. To "nešto" je viši nivo apstrakcije. OOP nije toliko tehnika programiranja, koliko način razmišljanja. Naravno najbolje je da jezik direktno podržava OOP - to omogućava da razmišljaš direktno koristeći njegova sredstva. Ali čak i na ne-objektnim jezicima, OO razmišljanje se itekako isplati.

Parafraziraću Bjarne Stroustrup-a, tvorca C++-a: Mali program (recimo 1000 linija) može da se napiše u bilo čemu, bilo kako. Ako si dovoljno vešt, na kraju ćeš ga naterati da radi. Ali u velikom programu, ako se nisi pridržavao "lepog programiranja" i koristio odgovarajuće tehnike - naročito OOP, nove greške će se pojavljivati jednako brzo kao što ispravljaš stare.

Razlog tome je što svaki deo programa zavisi od gomile drugih, ali te zavisnosti su toliko zamršene i neintuitivne da ih čak i tvorac teško prati. Kada promeniš jedan deo programa, ne možeš lako da sagledaš na čega sve u stvari to utiče. Naravno, valjanim procedurelnim programiranjem može se prilično dobro modularizovati program i izdvojiti ponovo upotrebljiv kod, ali ako tako radiš - onda već počinješ da misliš na OOP način. Ono što ti nedostaje je bolji način da organizuješ gomilu procedura koje si kroz praksu napisao i da ih bolje povežeš sa strukturama podataka kojima manipulišu.

Vratimo se malo na fakultet, definiciji tipa podataka: "Tip podataka je uređena dvojka čiji je prvi element skup svih dozvoljenih vrednosti za taj tip, a drugi element skup svih operacija koje nad tim vrednostima možemo izvršiti.". Tip je dvojstvo podataka i operacija nad njima.

Ako znaš šta je tip, onda znaš i šta je osnovni pojam OOP-a: klasa. Naime, klasa je ništa drugo do jezičko sredstvo da se definiše tip podataka. Iskompajliraj ovo u glavi: klasa je, znači, način da se u programskom jeziku procedure i funkcije eksplicitno povežu za strukturu podataka. Logično pitanje sledi: "Ali ja sam u parametre procedure mogao da stavim bilo šta - uključujući i strukturu podataka koja me interesuje - na taj način sam povezivao tip sa njegovim operacijama. U čemu je razlika?". Razlika je u (podebljanoj) reči "eksplicitno". U OOP-u procedure koje pripadaju klasi su na više načina "posebne" i sa njima se mogu raditi stvari nemoguće za "smrtne" procedure. Takve procedure se nazivaju metodi.

Pa, šta će ti to u životu? Evo četiri dobra razloga:

Pod jedan, ako imaš klasu Trougao i metod Crtaj (koji joj pripada i vrši iscrtavanje trougla), ništa te ne sprečava da napraviš i klasu Kvadrat koja takođe ima metod Crtaj (koji crta kvadrat). Iako se isto zovu, to su različiti metodi. Znači, štedimo imena i izbegavamo konflikte. Moduli (u Pascal-u su to unit-i) se mogu upotrebiti u ovu svrhu, a neki jezici pružaju i posebne mehanizme u borbi za dodeljivanje logičnih imena (na pr. C++ prostori imena - namespaces ili prilično unapređeni moduli Module-2). Ipak moduli su često preglomazni za ovoj zadatak, pogotovo ako su (kao na Pascal-u) vezani za fizičko skladištenje sorsa - fajlove. U Moduli-2, na primer, moduli mogu da sadrže i podmodule za koje je tačno definisano šta daju spoljašnjem svetu i šta iz njega vide, ali to pomalo liči na gađanje muve maljem od dve tone. Ovako, ako imaš promenljivu t klase Trougao i promenljivu k klase Kvadrat, trougao crtaš sa t.Crtaj a kvadrat sa k.Crtaj - šta ćeš jednostavnije?

A sada dođoh i do pojma objekat. Prosto, objekat je promenljiva neke klase. Drugi naziv je instanca ("primerak"). Klasa je definicija tipa, objekat je konkretan primerak klase. Na pr. kada kažemo da promenljiva t ima tip (klasu) Trougao, drugi način da kažemo to isto je: t je objekat tipa Trougao. Ma, da ne davim, t i k iz prethodnog pasusa su objekti.

Pod dva, svaka klasa može da sakrije ono što želi. Ako imaš pomoćno parče koda koje pozivaju samo metodi unutar klase, napravićeš privatan metod, nevidljiv spolja. Ako si pisao veće programe, ovo si opet radio preko modula (unit-a) sakrivanjem u implementation sekciju (cpp fajl kod C++-a). Međutim, opet rizikuješ da se zatrpaš gomilom modula od kojih svaki koristi svaki i koji su međusobno isprepletani više nego što bi zaista želeo. Ovakvo sakrivanje zove se enkapsulacija. Neki jezici, na pr. C++ i novije verzije Jave, čak mogu da imaju klase unutar drugih klasa, koje opet mogu da budu privatne.

Do sada, uz dovoljno samodiscipline, mogao si da preživiš koristeći klasična sredstva lepog programiranja - pre svega module. Sada ide nešto što se jednostavno ne može uraditi bez OOP-a.

Pod tri i najvažnije: Nasleđivanje je način da već postojeću "roditeljsku" klasu proširiš ili izmeniš i napraviš novu "klasu dete" koja ostaje povezana sa roditeljskom. Ovo je ključ onoga što englezi zovu code-reusability (ponovna iskoristivost koda). Ako već imaš klasu koja radi neznatno manje od onoga što ti treba, zašto ne iskoristiti taj već napisani kod i samo dopisati ono što ti treba? Naravno copy-and-paste programiranje može učiniti da veoma lako "iskoristiš" ono što je već napisano. Ali time dobijaš dve komadeške koda za koje samo ti znaš da bi trebalo da rade istu stvar - dok ne zaboraviš. Sada zamisli da si našao grešku u prvoj kopiji - to znači da treba treba da protrčiš kroz sve ostale i napraviš identične ispravke. Zamisli žurku kada imaš desetak kopija! Samo da te upozorim: nije neobično da ozbiljne biblioteke klasa (kakav je Delphi-jev VCL) imaju i po nekoliko desetina nivoa nasleđivanja. Kakav bi to bio haos da je u pitanju prosto kopiranje istog koda! A efikasnosti se još nismo ni dotakli.

Međutim, kada se sa napravi pravo nasleđivanje, ako promeniš kod u roditeljskoj klasi, automatski si promenio i svu decu. Sa druge strane, u većini jezika, decu možeš dodavati bez rekompajliranja roditelja, obično čak ni ceo izvorni kod nije potreban - dosta je samo interfejs (deklaracija klasa/ metoda bez definicije). Naravno, nema višestrukog kompajliranja (interpretiranja) jednog te istog, pa je sve brže i zauzima manje mesta. Do sada sam govorio uglavnom o metodima, ali nasleđivanjem možeš dodati i nova polja, no o-tom-po-tom (još ne znaš ni kako jedna klasa izgleda kad se napiše u konkretnom programskom jeziku).

Četvrto, tesno povezano sa nasleđivanjem: polimorfizam. Ovo je nešto o čega se početnici u OOP-u najlakše spotaknu, pa nemoj da se sekiraš ako ne svariš sve odmah. Kada naslediš neku klasu, na fizičkom nivou joj dodaš/promeniš metode ili članove (polja), ali na logičkom nivou, ti samo praviš novu vrstu te klase. A'jmo sad, iz neba pa u rebra, pa ko shvati, razumeće: dete jeste roditelj. To znači: tamo gde stoji roditelj, mogu da stavim i dete, naprosto zato što dete sadrži sve što i roditelj (iako verovatno i nešto preko toga). Uoči da obrnuto ne važi. Naime, roditelj nije dete - dete sadrži i nešto što roditelj nema, pa roditelja ne možemo da stavimo svuda gde možemo dete jer će nešto da nam zafali.

A sada suština: čak iako dete stavimo mesto roditelja, ono i dalje ostaje dete. Ako pozovemo metod koji postoji i u roditelju i u detetu, koja od ove dve verzije metoda će biti pozvana zavisi od toga da li smo u vreme izvršavanja stavili roditelja ili dete. Ako smo stavili dete, biće pozvan metod deteta. Na pr. bez obzira što je u vreme kompajliranja parametar neke procedure deklarisan kao roditelj, u vreme izvršavanja možemo u njega da stavimo dete, i ono će nastaviti da se ponaša kao dete.

Inače, ovo je razlog za korišćenje pokazivača u OOP-u.

Dakle suština polimorfizma je: Objekti se isto koriste ali se različito - u skladu sa svojom konkretnom klasom - ponašaju. U vreme kompajliranja nemamo način da odredimo koji će konkretni objekti to biti, ali u vreme izvršavanja za svaki objekat se pozivaju metode klase kojoj pripada, a ne roditeljske klase koja je deklarisana u vreme kompajliranja.

Da opet pozovem u pomoć Bjarne Stroustrup-a: Programski jezik ima dva aspekta: jedan omogućava da mašini narediš šta da radi, a drugi predstavlja konceptualni alat koga ti sam koristiš u razmišljanju o tome kako rešiti problem. Principi koje sam izložio ne samo da postoje u svakom pristojnom objektnom jeziku, već predstavljaju jako dobar način apstrakcije. Više se nećeš gušiti u detaljima dijagrama toga, već ćeš se izmaći, pogledati problem sa visine i početi da ga raščlanjuješ na objekte koji u njemu učestvuje. Te objekte ćeš razvrstati u logične "stablaste" strukture - hijererhije nasleđivanja.

Nasledjivanje


Jedno od najvažnijih (i još uvek samo delimično rešenih) pitanja u programiranju glasi: "Kako ne izmišljati ponovo točak?". Malo drugačije formulisano, problem glasi: kako napisati nešto, a da se to nešto može upotrebiti što više puta? Priznajem, zvuči čudno.

Ipak, svako ko je iole intenzivnije programirao, pisao je mnogo puta sličan (ili isti!) kod u različitim programima ili čak istom programu.

Zbog čega?

Ima više razloga - jedan je tradicionalna lenjost programera. Naprosto, bilo je jednostavnije ad-hoc uraditi tačno ono što treba, tačno tamo gde treba, nego pokušati izdvojiti opšte rešenje koje bi se kasnije specijalizovalo na konkretne slučajeve. Takvo "copy-and-paste" programiranje, u kome samo prepišeš (i po potrebi izmeniš) kod¸ predstavlja sredstvo da se program završi brzo i da se brzo natera da radi. Ali reč "brzo" u ovom slučaju znači "kuso" - i jeste noćna mora kada je održavanje i nadogradnja u pitanju.

Da ne krivimo samo programere, ni jezici nisu podržavali "apstraktni" način razmišljanja koji bi omogućio da razmišljaš u pojmovima bliskim problemu a ne u pojmovima, kakvi su bajtovi i pokazivači, bliskim mašini.

U klasičnom, "proceduralnom" ili "strukturnom" programiranju postoje tehnike da se kod, koji radi neku opštu stvar, izdvoji i ponovo upotrebi (mada neki popularni xBase jezici čak i u tome veoma šantaju). Najznačajnije je postajanje "procedura", "funkcija" ili "potprograma". Druga tehnika su moduli, koji se zapravo javljaju u tri uloge: enkapsulacija, ponovna upotreba koda kroz procedure koje se u njima nalaze i (u većini jezika) fizička organizacija - moduli su često u bijekciji sa fajlovima.

Čini se da ovo rešava problem ponovne upotrebljivosti koda, ali na duže staze (i u većim programima) to jednostavno nije to - upadamo u zamku razmišljanja na nivou mašine, a ne problema.

Postoje bolja, objektna, rešenja koja ne negiraju te klasične tehnike, već ih organizuju na jednom višem nivou. Ključno od njih je nasleđivanje (engl. inheritance).

Pogledaj O objektno orjentisanom programiranju za još malo argumentacije šta će nam uopšte ponovna upotrebljivost koda (engl. code-reusability) i šta su osnovni pojmovi OOP-a koje ću koristiti u priči koja sledi.

Nasleđivanje je način da već postojeću klasu proširiš ili izmeniš, praveći njenu naslednicu (dete) u kojoj napišeš samo to što je promenjeno ili izmenjeno. Sve ostalo, ona nasleđuje od roditelja. Bitno je da klasa dete ostaje vezana za roditelja - kada se roditelj promeni, time se automatski menjaju i sva njegova deca, u onim svojim delovima koje su nasledila od roditelja. Time, ako ispraviš bag u roditelju, ispravio si bag u svoj deci; ako nadogradiš roditelja nadogradio si svu decu.

Sada bi bio red da dam primer, a upravo su primeri nezgodna tačka objašnjavanja OOP-a. Naime pimeri su mali, a upravo na male količine koda odnosi se ona primedba Bjarne Stroustrup-a "da se mali program može napisati bilo kako ako si dovoljno vešt". Na žalost nije praktično davati primere od 10000 linija, pa nemoj odmah da se buniš: "Ali ovo sam ja radio klasičnim tehnikama...".

Recimo da nam treba klasa koja crta kvadrat:



Pisaću na objektnom Paskalu, Delphi-jevom jeziku. Namerno ću je oblikovati tako da ispočetka nije najsažetija, ali da se može dobro naslediti.

// Ovo ide u interface sekciju Pascal-ovog unit-a.
type
Square = class
private
Visible: boolean; // false ako je nevidljiv.
X,Y: integer; // Koordinate centra.
A: integer; // Duzina stranice.
protected
// Fizicki crta na osnovu X,Y,A.
procedure Draw; virtual;
// Brise i obnavlja pozadinu.
procedure Clear; virtual;
public
procedure Place(x_arg,y_arg: integer); // Pozicioniraj.
procedure SetA(a_arg: integer); // Postavi stranicu.
procedure Show; // Prikazi kvadrat.
procedure Hide; // Sakrij ga.
end;
// Ovo se stavlja u implementation sekciju Pascal-ovog unit-a.
procedure Square.Draw;
begin
// Crtaj kvadrat sa stranicom A, na poziciji X,Y.
end;
procedure Square.Clear;
begin
// Izbrisi kvadrat i obnovi pozadinu.
end;
procedure Square.Place(x_arg,y_arg: integer);
begin
X := x_arg;
Y := y_arg;
if Visible then
Show; // Da bi se po potrebi pozvao i Clear.
end;
procedure Square.SetA(a_arg: integer);
begin
A := a_arg;
if Visible then
Show;
end;
procedure Square.Show;
begin
if Visible then
Clear
else
Visible := true;
Draw
end;
procedure Square.Hide;
begin
if Visible then
begin
Clear;
Visible := false
end
end;
Pogledaj "Enkapsulacija" za objašnjenje šta znače public, protected i private.

Ovo je jedan živahan kvadrat koji se automatski pomeri kada mu promeniš veličinu ili poziciju, pri čemu pazi da ne ostavi đubre za sobom - automatski se izbriše ono što je iscrtao dok je bio na prethodnoj poziciji/veličini. Kako to brisanje (i iscrtavanje) fizički realizovati jedna je druga tema koja jako zavisi od konkretnog jezika i ciljne platforme - za naš primer to je totalno nebitno.

Takođe, metodi Draw i Show su deklarisani kao virtuelni. Ovo je jedan pojam vezan za polimorfizam - objasniću ga za trenutak.

Sada, recimo da hoćemo da napravimo dvostruki kvadrat koji se sastoji iz jednog spoljašnjeg i jednog unutrašnjeg:



Uočimo da da ovaj dvostruki kvadrat ima dosta zajedničkog sa "normalinom" jednostrukim - moraju mu se znati koordinate centra i dužina stranice. Postoji jedan detalj koji je nov - dužina stranice drugog kvadrata (A1).

Pa zašto onda ne bismo iskoristili ono što smo već napisali (klasu Square) i samo dodali taj novi detalj - prava prilika za nasleđivanje. Suma sumarum, treba uraditi tri stvari:

Dodati metod kojim zadajemo dužinu stranice drugog kvadrata.
Proširiti metod koji crta kvadrat, tako da iscrta i drugi kvadrat. Najzgodnije je pozvati već postojeći metod Square.Draw, a zatim samo dopisati kod koji crta drugi kvadrat.
Proširiti metod koji briše kvadrat, tako da izbriše i drugi kvadrat. Kao i pod 2), pozvaćemo već postojeći metod Square.Clear, uz dopisivanje koda za brisanje drugog kvadrata.
Naravno treba naterati već napisane metode koji pozivaju Draw i Clear da pozovu baš ove nove, izmenjene, verzije. Opet uočite da su one deklarisane kao virtuelne i strpite se još malo do konačnog objašnjenja.

Evo koda:

type
DoubleSquare = class(Square)
private
A1: integer; // Stranica drugog kvadrata.
protected
procedure Draw; override;
procedure Clear; override;
public
procedure SetA1(a1_arg: integer);
end;
procedure DoubleSquare.Draw;
begin
inherited; // Poziva Square.Draw.
// Ovde treba iscrtati kvadrat staranice A1.
end;
procedure DoubleSquare.Clear;
begin
// Ovde treba izbrisati kvadrat staranice A1.
inherited; // Poziva Square.Clear.
end;
procedure DoubleSquare.SetA1(a1_arg: integer);
begin
A1 := a1_arg;
if Visible then
Show;
end;
Napomena: override je kljucna reč Delphi-ja koja označava da nasleđujemo virtualnu metodu. Neki jezici (C++) ne zahtevaju nikakve ključne reči.

Znači, dobili smo dvostruki kvadrat koji uz metode iz klase Square ima i metod SetA1 (postavlja dužinu stranice drugog kvadrata) i koji se, začudo, ispravno iscrtava iako nismo direktno promenili stare javne metode. Ali promenili smo metode za iscrtavanje koji su od početka bili deklarisani kao virtuelni i time naterali Show da pozove novi DoubleSquare.Draw i DoubleSquare.Clear, a ne Square.Draw i Square.Clear. Isto se desilo za Hide, a pošto se ostali metodi oslanjaju na Show i Hide, time i oni posredno pozivaju ispravne Draw i Clear.

Pa šta su virtuelni metodi? To su metodi koji se pozivaju u zavisnosti od toga za koju klasu (zadatu u vreme izvršavanja) su pozvani. Drugim rečima, koji će virtuelni metod biti pozvan ne zavisi od deklaracije klase u vreme kompajliranja, već od toga koje je klase objekat za koga pozivamo metod u vreme izvršavanja.

U ovom konkretnom slučaju, (na primer) Show je deklarisan kao metod klase Square i sledstveno tome poziva Square.Draw. Da Draw nije virtuelan, i kada pozovemo Show za objekat klase naslednice kakva je DoubleSquare, on bi pozivao metode koje je originalno pozivao. Znači pozvao bi Square.Draw. Međutim, pošto je Draw virtuelan, Show će prvo proveriti koja je klasa objekta za koga je pozvan i pozvaće metod te klase - znači DoubleSquare.Draw.

Kako koristimo dobijenu klasu? Isto kao i početnu!

// ds je tipa DoubleSquare.
ds.Place(100,50);
ds.SetA(40);
ds.SetA1(30);
ds.Show // Bice pozvan DoubleSquare.Draw.
Odmakni se sada korak unazad i pogledaj šta smo dobili. Sa izuzetno malo koda napravili smo klasu DoubleSquare. Ostavili smo mogućnost da i DoubleSquare bude nasleđena (u na pr. TripleSquare). I na kraju, ako klasi Square (na pr.) dodamo mogućnost da menja boju, sve njegove naslednice će dobiti tu mogućnost.

Ovde je izložen i jedan važan slučaj polimorfizma, a za još primera pogledaj "Polimorfizam".


--------------------------------------------------------------------------------

Još neke tehnike za ponovnu upotrebu koda

Komponente su samo specijalne klase koje mogu da se vizuelno programiraju i predstavljaju osnovu za RAD (Rapid Application Development - brz razvoj aplikacija). Objektno-orjentisane biblioteke komponenti, kakva je Delphi-jev VCL, predstavljaju istovremeno i veliku, razgranatu hijerarhiju nasleđivanja. Primer moći ovakvog koncepta predstavlja Anchor property, koji je, u verziji 4, dodat jednoj od osnovnih klasa VCL-a, čime su sve vizuelne komponente (njene naslednica) dobile tu istu osobinu - moćniju kontrolu pozicioniranja na formi!

Neki jezici, kao što je Visual Basic, nemaju mogućnost pravog nasleđivanja od strane programera (VB za sada podržava samo tzv. nasleđivanje interfejsa), ali podržavaju komponente koje su obično interno objektno orjentisane. Biblioteke ovakvih komponenti su po pravilu manje elegantne.

Jedna od novijih (i spektakularnijih) tehnika za ponovno iskorišćavanje već napisanog koda je i takozvano generičko programiranje. Od komercijalnijih jezika C++ i, na jednom drugom nivou, Java imaju podršku za njega. Generičko programiranje samo po sebi ne mora da bude vezano za OOP, ali mu njegovo prisustvo veoma prija. Ali to je već druga (i duga) tema.

OOP i pokazivaci


Ako si programirao u alatima poput Delphi-ja ili Jave, verovatno si uočio da se promenljive koje ne pripadaju nekom osnovnom tipu, nego su primerci (instance) klase, ne ponašaju baš očekivano. To je zbog toga što u pitanju nisu objekti već pokazivači na njih!

Verovatno si u početku bio zbunjen zašto se u Delphi-ju mora zadati Owner ili dobro paziti da se pozove Free, C++ ima new i delete (ili u boljem slučaju nekekav auto_ptr), a Java ima "sakupljač smeća". Evo u čemu je stvar.

Naime, objekti koji se u vreme izvršavanja stavljaju na potrebna mesta u programu (kao parametri funkcija i sl.) ne moraju da budu instance (primerci) one klase koja je tu deklarisana u vreme kompajlieranja, već mogu da budu iz neke klase NASLEDNICE. Znači možeš da deklarišeš funkciju koja kao parametar prima klasu Roditelj, a u vreme izvršavanja pozoveš je prosleđujući joj parametar klase Dete.

Sposobnost da mesto klase roditelja staviš klasu dete značajna je za polimorfizam - dete se ponaša slično, a opet na svoj način.

Pa u čemu je problem? Naime, prosti tipovi imaju tačno određenu veličinu i strukturu. Zbog toga promenljiva preko koje pristupaš prostom tipu u sebi samoj sadrži objekat (instancu, primerak) tog tipa. Drugim rečima, kada upotrebiš promenljivu prostog tipa, ti direktno pristupaš komadu memorije koji leži "pod njom".

Kod klasa, situacija se iz korena menja. Kada napraviš svoju klasu, kompajler tačno zna (izračuna) koje je veličine, t.j. koliko memorije treba za nju i na kojim mestima se nalaze njena polja. Međutim, pošto mesto roditeljske klase možeš da staviš dete (čiji se tip, pa ni veličina i interna struktura, ne zna u vreme kompajliranja, već samo u vreme izvršavanja), kompajler dolazi u nezgodnu situaciju da NE ZNA koliko memorije treba da odvoji za nju. A to znanje je jednostavno NEOPHODNO za ostvarivanje mehanizama kakav je pozivanje funkcija (tu se koristi struktura podataka koja se zove stek). Zbog toga se pribegava triku.

Ono što je u Delphi-ju promenljiva class tipa, a u Javi se zove "reference type" je u stvari POKAZIVAČ (pointer) na stvarni objekat. Pokazivač je promenljiva koja sadrži memorijsku ADRESU druge promenljive i time "pokazuje" na nju. Zbog toga, kada praviš promenljivu koja pripada nekoj klasi, ti u stvari (implicitno) praviš dva objekta: 1) objekat klase i 2) pokazivač (referencu) na njega. Objektu klase u stavari ne pristupaš direktno, već preko pokazivača.

Zašto je to dobro? Zato sto je pokazivač u stvari celobrojna promenljiva čija se veličina tačno zna, pa kompajler njime može slobodno da manipuliše.

Inače, "referenca" i "pokazivač" su manje-više sinonimi, samo što se "referenca" više upotrebljava u jezicima u kojima je rad sa njima automatizovan. Verovatno si čuo da Java nema pokazivače. Java u stvari vrvi od pokazivača, samo što su namenjeni isključivo u objektne svrhe i ne postoji mogućnost za (veruj mi) podmukle greške tipa:

"Pokazivač pokazuje na nepostojeći objekat" (tzv. viseći pokazivač) - jer ne možeš da deklarišeš referencu, a da ona ne pokazuje na neki objekat, niti tu referencu možeš kasnije da promeniš tako da ne pokazuje ni na šta.
"Objekat postoji, ali mu se ne može pristupiti jer ne postoji ni jedan pokazivač na njega" (tzv. memory leaking - curenje memorije) - jer Java ima "skupljanje smeća" (garbage collecting). Java virtuelna mašina automatski "broji" reference na neki objekat, i kada ih više nema, automatski uništava objekat.
Delphi, pak nije toliko zaštićen od ovakvih grešaka. Ako deklarišeš promenljivu a ne dodeliš joj vrednost sa promenljiva:=klasa.Create, ti u stvari imaš viseći pokazivač. Ako pak uništiš objekat, u referenci ostaje adresa na kojoj je objekat nekada bio. Ako pak izvršiš Create, a ne zadaš Owner ili izvršiš Free, dobio si curenje memorije. C++ ima slične probleme.

Upotreba ovakvog "pokazivačkog" objektnog modela ima jednu slabost (ili barem osobinu o kojoj se mora voditi računa). Kada dodeljuješ jednu reference promenljivu drugoj, ti u stvari kopiraš samo pokazivač, a ne i objekat na koga pokazuje. To te u ovom slučaju ostavlja sa dve reference na isti objekat. Onaj drugi objekat će verovatno u slučaju Jave odmah biti počišćen od strane garbage collector-a, a u drugim jezicima postaje memory leak. Ako to nije ono što si želeo, treba da upotrebiš poseban metod (na pr. Delphi-jev Assign) koji će da napravi efektivnu kopiju objekta klase a ne samo pokazivača.