Forum » Programska oprema » Java je OOP ??
Java je OOP ??
Glodko ::
Glihkar sem se spravu malo k Javi in spet sem pred objektno/predmetno usmerjenim programiranjem. V teoriji vem da Java to je, ne znam pa si tega predstavlat (sem začetnik, tko da nimam drugje podlage). Samo kaj to natančno pomeni v praksi, kje se to odraža? Kakšno je pa neobjektno programiranje? Kako bi to po domače povedal da bi razumel amater - jaz recimo 
in si s tem kej pomagal pri samem razumevanju koncepta programiranja?
in si s tem kej pomagal pri samem razumevanju koncepta programiranja? Ice-Heki ::
No, mogoče bom udaril mimo.
Objektno programiranje je programiranje, kjer je velik del kode napisan kot funkcije in razredi (no, ne samo to, tudi druge prednosti ima).
Razred lahko vsebuje n funkcij, ki so med seboj (smiselno) povezane.
Prednost je ta, da lahko večino funkcij kadarkoli prenesemo iz enega v drug projekt; funkciji navadno podamo vhodne parametre, le ta pa iz njih nekaj naredi in nam da nek nov podatek.
Primer:
Funkcijo Zenska lahko kadarkoli vzamemo iz razreda Ljudje in jo lahko damo tudi kam drugam - npr. v razred Zaposleni, če želimo preverjati spol zaposlenih in le ta bo delala.
Razlika med objektnim in proceduralnim je predvsem v tem, da pri objektnem združimo določene funkcije v razrede (ni obvezno), vendar s tem zmanjšamo količino pisanja kode / koda za posamezno obdelavo podatkov je zapisana enkrat.
Nasprotno od objektnega programiranja pa je proceduralno programiranje. V tem primeru moramo vedno pisati kodo; torej je končni rezultat lahko to, da imamo v več datotekah podobne oz. enake dele datoteke, ker pač na tistih mestih izvajamo zahtevano obdelavo podatkov.
Primer proceduralnega načina - ki je podoben zgornjemu:
Objektno programiranje je primerno predvsem za velike projekte, ker se lažje vzdržuje red. V nasprotnem primeru bi bilo težko programirat vse igre, desktop aplikacije.
Za večje projekte se ponavadi vzame že razvite frameworke (oz. se razvije svojega), pri tem pa je ena slabost (no, niti ni slabost) - le tega se je potrebno predhodno naučiti (mogoče se sliši zguba časa, ker se pač nekaj časa porabi samo za učenje kako vse skupaj izgleda, a na dolgi rok se splače, ker če bi morali najprej naštudirati vsako aplikacijo posebaj bi trajalo še dalj časa).
Mogoče bi kot veliko prednost objektnega programiranja navedel še dedovanje, a več o tem pa kdaj drugič.
Okej, dost moje filozofije.
Ena debata o tem je že bila nekoč na PHP-SI.com in sicer v temi objektno in ..."klasično"
P.S: Od kdaj je prepovedana oznaka < code > ?
Objektno programiranje je programiranje, kjer je velik del kode napisan kot funkcije in razredi (no, ne samo to, tudi druge prednosti ima).
Razred lahko vsebuje n funkcij, ki so med seboj (smiselno) povezane.
Prednost je ta, da lahko večino funkcij kadarkoli prenesemo iz enega v drug projekt; funkciji navadno podamo vhodne parametre, le ta pa iz njih nekaj naredi in nam da nek nov podatek.
Primer:
razred Ljudje
{
funkcija Zenska($spol)
{
// če je spremenljivka $spol = ženska potem je odgovor DA
// v nasprotnem primeru pa ne
}
}
Funkcijo Zenska lahko kadarkoli vzamemo iz razreda Ljudje in jo lahko damo tudi kam drugam - npr. v razred Zaposleni, če želimo preverjati spol zaposlenih in le ta bo delala.
Razlika med objektnim in proceduralnim je predvsem v tem, da pri objektnem združimo določene funkcije v razrede (ni obvezno), vendar s tem zmanjšamo količino pisanja kode / koda za posamezno obdelavo podatkov je zapisana enkrat.
Nasprotno od objektnega programiranja pa je proceduralno programiranje. V tem primeru moramo vedno pisati kodo; torej je končni rezultat lahko to, da imamo v več datotekah podobne oz. enake dele datoteke, ker pač na tistih mestih izvajamo zahtevano obdelavo podatkov.
Primer proceduralnega načina - ki je podoben zgornjemu:
$spol = $_GET['spol'];
if($spol == 'Zenska')
{
echo "Ti si ženska";
}
else($spol == 'Moski')
{
echo "Ti si pa fant";
}
Objektno programiranje je primerno predvsem za velike projekte, ker se lažje vzdržuje red. V nasprotnem primeru bi bilo težko programirat vse igre, desktop aplikacije.
Za večje projekte se ponavadi vzame že razvite frameworke (oz. se razvije svojega), pri tem pa je ena slabost (no, niti ni slabost) - le tega se je potrebno predhodno naučiti (mogoče se sliši zguba časa, ker se pač nekaj časa porabi samo za učenje kako vse skupaj izgleda, a na dolgi rok se splače, ker če bi morali najprej naštudirati vsako aplikacijo posebaj bi trajalo še dalj časa).
Mogoče bi kot veliko prednost objektnega programiranja navedel še dedovanje, a več o tem pa kdaj drugič.
Okej, dost moje filozofije.
Ena debata o tem je že bila nekoč na PHP-SI.com in sicer v temi objektno in ..."klasično"
P.S: Od kdaj je prepovedana oznaka < code > ?
]Fusion[ ::
http://www.jugsi.net/dokumentacija/Knji...
Evo to so nas učili na FERIju. Predvsem si lahko pogledaš 2. poglavje kjer so opisani OO koncepti. OOP je neka nadgradnja funkcijskega programiranja, kjer si imel samo funkcije, pri OOP pa te ogradiš v razrede. Te funkcionalnosti tako lahko lepo ločiš po razredih in pridobiš na jasnosti in prilagodljivosti kode. zraven so še seveda dodatni principi kot so dedovanje, ki še povečajo prilagodljivost.
Evo to so nas učili na FERIju. Predvsem si lahko pogledaš 2. poglavje kjer so opisani OO koncepti. OOP je neka nadgradnja funkcijskega programiranja, kjer si imel samo funkcije, pri OOP pa te ogradiš v razrede. Te funkcionalnosti tako lahko lepo ločiš po razredih in pridobiš na jasnosti in prilagodljivosti kode. zraven so še seveda dodatni principi kot so dedovanje, ki še povečajo prilagodljivost.
"I am not an animal! I am a human being! I... am... a man!" - John Merrick
netanyahu ::
OOP je neka nadgradnja funkcijskega programiranja
s/funkcijskega/proceduralnega/
Čisto druga stvar.
s/funkcijskega/proceduralnega/
Čisto druga stvar.
imagodei ::
Ice-Heki@ Objektno programiranje je programiranje, kjer je velik del kode napisan kot funkcije in razredi (no, ne samo to, tudi druge prednosti ima).
Zelo poenostavljeno :OOP je programiranje, kjer so posamezni programski problemi predstavljeni kot en ali več objektov. Lahko gre za prevajanje resničnih objektov, lahko pa gre za abstrakcijo.
Konkretno - če izdeluješ aplikacijo ala instant messaging (npr MSN-like), lahko uporabniški vmesnik predstaviš kot en objekt, del kode, ki pa je namenjen dejanskemu pošiljanju napisanega sporočila, pa kot drug objekt. Del kode, ki bi sprejemal, je lahko tretji objekt.
Vsak objekt je v tem primeru odgovoren samo za svoj ozek namen. Uporabniški vmesnik samo sprejema tekst (iz tipkovnice in iz interneta), skrbi, da je tekst pravilno predstavljen ipd. Ko objekt zazna, da si pritisnil Enter, preda tekst drugemu objektu, ki je odgovoren za pošiljanje teksta po internetu. Tega objekta ne zanima, kako je tekst nastal, niti, ali je pravilno zapisan na zaslonu. Naloga tega objekta je, da tekst ustrezno spakira in pošlje po netu. Enako tretji objekt - ko prejme podatke iz interneta, jih mora ustrezno obdelati, nato pa jih pošlje prvemu objektu, ki jih prikaže na zaslonu.
Objekti imajo običajno svoje lastnosti/spremenljivke in metode. V primeru drugega objekta, ki pošilja sporočilo po internetu, bi bila spremenljivka npr. podatek, ali je zadnje pošiljanje uspelo ali ne. Metoda pa bi bila funkcija, ki bi pravzaprav izpeljala pošiljanje.
Objekti med seboj komunicirajo v idealnem primeru s pošiljanjem sporočil (Message Passing). Na ta način npr. drugi objekt zgornjega primera obvesti prvi objekt (uporabniški vmesnik), da je pošiljanje uspelo in naj poslani tekst prestavi iz vnosne vrstice v okno pogovora. Ko prvi objekt prejme to sporočilo, izvede svojo metodo, ki zahtevo izvede.
Prednost tega načina je, da je vsak objekt zaključena celota. Če nekaj spremenimo v enem objektu, drugih ni treba praktično nič popravljati (le, če pride do spremembe v tistem delu, ki komunicira z drugimi objekti). Objekti pač ponujajo nek standarden vmesnik drugim objektom, kaj pa je "pod pokrovom", pa drugim objektom ni potrebno vedeti. Približno tako, kot se lahko katerikoli voznik usede v katerikoli avto in takoj najde sklopko, zavoro, plin in prestavno ročico. Da lahko vozi avto, pa mu ni treba vedeti prav nič o tem, kako deluje motor.
Skratka, pri objektnem programiranju je vsak objekt zaključena celota in skrbi sam zase. Npr, da želiš simulirat gibanje biljard kuglic po biljard mizi. Spišeš program, ki ustvari devet objektov tipa Krogla, katere spremenljivke/lastnosti so (med drugim) Hitrost, Smer, PoložajXY, Teža, (bela krogla je nekoliko večja in težja). Metode pa so (med drugim) IzračunajNovoSmer, Izračunaj novo hitrost...
Ko poženeš simulator, ta v vsaki ponovitvi zanke cikla skozi vse kugle in vsaka kugla zase pogleda, kje se je nahajala v prejšnjem koraku, kakšno smer in hitrost ima ter izračuna, kam se bo premaknila. Nov položaj vrne simulatorju, da ga ta izriše na zaslonu. (Nekako tako, no, mogoče sem se v kakšni malenkosti ob tej pozni uri zapletel...)
Pri proceduralnem programiranju koda običajno ni tako striktno ločena. Četudi delaš s funkcijami in dele programa pišeš kot funkcije. Koda se tam pač izvaja od začetka do konca oz. teče v zanki, dokler ni izpolnjen pogoj, da se konča. Koda ni tako lepo organizirana, ni obveščanja s sporočili, pojavijo se problemi z interfejsi... Recimo, da na dveh delih programa uporabljaš isto funkcijo za pošiljanje podatkov po internetu in bi rad ugotovil, ali je šlo pošiljanje v redu. V OOP boš zgolj vrnil sporočilo objektu, ki je zahteval pošiljanje, v proceduralnem programiranju moraš sam poskrbeti za branje statusa pošiljanja. In še bi lahko našteval.
Pač, za določene rešitve je primerno proceduralno programiranje, za druge OOP.
Zelo poenostavljeno :OOP je programiranje, kjer so posamezni programski problemi predstavljeni kot en ali več objektov. Lahko gre za prevajanje resničnih objektov, lahko pa gre za abstrakcijo.
Konkretno - če izdeluješ aplikacijo ala instant messaging (npr MSN-like), lahko uporabniški vmesnik predstaviš kot en objekt, del kode, ki pa je namenjen dejanskemu pošiljanju napisanega sporočila, pa kot drug objekt. Del kode, ki bi sprejemal, je lahko tretji objekt.
Vsak objekt je v tem primeru odgovoren samo za svoj ozek namen. Uporabniški vmesnik samo sprejema tekst (iz tipkovnice in iz interneta), skrbi, da je tekst pravilno predstavljen ipd. Ko objekt zazna, da si pritisnil Enter, preda tekst drugemu objektu, ki je odgovoren za pošiljanje teksta po internetu. Tega objekta ne zanima, kako je tekst nastal, niti, ali je pravilno zapisan na zaslonu. Naloga tega objekta je, da tekst ustrezno spakira in pošlje po netu. Enako tretji objekt - ko prejme podatke iz interneta, jih mora ustrezno obdelati, nato pa jih pošlje prvemu objektu, ki jih prikaže na zaslonu.
Objekti imajo običajno svoje lastnosti/spremenljivke in metode. V primeru drugega objekta, ki pošilja sporočilo po internetu, bi bila spremenljivka npr. podatek, ali je zadnje pošiljanje uspelo ali ne. Metoda pa bi bila funkcija, ki bi pravzaprav izpeljala pošiljanje.
Objekti med seboj komunicirajo v idealnem primeru s pošiljanjem sporočil (Message Passing). Na ta način npr. drugi objekt zgornjega primera obvesti prvi objekt (uporabniški vmesnik), da je pošiljanje uspelo in naj poslani tekst prestavi iz vnosne vrstice v okno pogovora. Ko prvi objekt prejme to sporočilo, izvede svojo metodo, ki zahtevo izvede.
Prednost tega načina je, da je vsak objekt zaključena celota. Če nekaj spremenimo v enem objektu, drugih ni treba praktično nič popravljati (le, če pride do spremembe v tistem delu, ki komunicira z drugimi objekti). Objekti pač ponujajo nek standarden vmesnik drugim objektom, kaj pa je "pod pokrovom", pa drugim objektom ni potrebno vedeti. Približno tako, kot se lahko katerikoli voznik usede v katerikoli avto in takoj najde sklopko, zavoro, plin in prestavno ročico. Da lahko vozi avto, pa mu ni treba vedeti prav nič o tem, kako deluje motor.
Skratka, pri objektnem programiranju je vsak objekt zaključena celota in skrbi sam zase. Npr, da želiš simulirat gibanje biljard kuglic po biljard mizi. Spišeš program, ki ustvari devet objektov tipa Krogla, katere spremenljivke/lastnosti so (med drugim) Hitrost, Smer, PoložajXY, Teža, (bela krogla je nekoliko večja in težja). Metode pa so (med drugim) IzračunajNovoSmer, Izračunaj novo hitrost...
Ko poženeš simulator, ta v vsaki ponovitvi zanke cikla skozi vse kugle in vsaka kugla zase pogleda, kje se je nahajala v prejšnjem koraku, kakšno smer in hitrost ima ter izračuna, kam se bo premaknila. Nov položaj vrne simulatorju, da ga ta izriše na zaslonu. (Nekako tako, no, mogoče sem se v kakšni malenkosti ob tej pozni uri zapletel...)
Pri proceduralnem programiranju koda običajno ni tako striktno ločena. Četudi delaš s funkcijami in dele programa pišeš kot funkcije. Koda se tam pač izvaja od začetka do konca oz. teče v zanki, dokler ni izpolnjen pogoj, da se konča. Koda ni tako lepo organizirana, ni obveščanja s sporočili, pojavijo se problemi z interfejsi... Recimo, da na dveh delih programa uporabljaš isto funkcijo za pošiljanje podatkov po internetu in bi rad ugotovil, ali je šlo pošiljanje v redu. V OOP boš zgolj vrnil sporočilo objektu, ki je zahteval pošiljanje, v proceduralnem programiranju moraš sam poskrbeti za branje statusa pošiljanja. In še bi lahko našteval.
Pač, za določene rešitve je primerno proceduralno programiranje, za druge OOP.
- Hoc est qui sumus -
Glodko ::
Se pravi se ta dostopna določila private/public/protected rabijo zarad teh objektov? Recimo private, da drug objekt ne posega/ ne vidi v kodo prvega, ampak da od njega samo dobi cifro ali recimo podatek je uspelo ni uspelo pošiljanja, za primer msn-ja?
imagodei ::
Poenostavljeno rečeno - ja.
Čeprav v primeru uspešnega/neuspešnega pošiljanja bi bilo bolj smotrno, če bi kar objekt za pošiljanje poslal obvestilo (mal zakomplicirano, ravno tak smešen primer), kako je s tekstom - ali je bilo uspešno poslano na net, ali ne.
Drugače pa, ja. Objektu pripraviš interface, s katerim komunicira z drugimi objekti. Ti potem lahko berejo javno dostopne spremenljivke, objekt ima pa lahko za svoje namene še cel kup notranjih. Enako velja za metode.
Čeprav v primeru uspešnega/neuspešnega pošiljanja bi bilo bolj smotrno, če bi kar objekt za pošiljanje poslal obvestilo (mal zakomplicirano, ravno tak smešen primer), kako je s tekstom - ali je bilo uspešno poslano na net, ali ne.
Drugače pa, ja. Objektu pripraviš interface, s katerim komunicira z drugimi objekti. Ti potem lahko berejo javno dostopne spremenljivke, objekt ima pa lahko za svoje namene še cel kup notranjih. Enako velja za metode.
- Hoc est qui sumus -
Glodko ::
No še eno smešno vprašanje. Čemu pol razredi? Recimo za primer spet MSN. Imaš nek objekt recimo k ti pobira znake ki jih vpisuješ, druzga ki ti jih pošilja in spet enga ki jih na drugmu pc-ju izpiše. A to zahteva 3 razrede al kako? Lahko vse 3 združiš v 1 razred? Kje pa veš da moreš postaviti main metodo?
Pa še tole me bega v Javi imamo primitivni tipe, med drugim tudi char, ki predstavlja eno črko/znak npr. ´a´! Potem lahko spišemo več teh črk npr. ´anja´ in to ni več char ampak je String? In pol kr naenkrat se urine vmes še StringBuffer!?! Moje vprašanje, zakaj sploh to rabmo? Zakaj je en znak char, dva in več očitno String in če želiš delat z njimi še StringBuffer. Kje se to sploh rabi? Pri spremenljivkah? Recimo stavek:
System.out.print ("danes je lep dan"); // ali so besedice "danes je lep dan" obravnavane kot String? Recimo da bi želel notri urivat, obračat, dodajat, chare kako bi potem to nardil?
Pa še tole me bega v Javi imamo primitivni tipe, med drugim tudi char, ki predstavlja eno črko/znak npr. ´a´! Potem lahko spišemo več teh črk npr. ´anja´ in to ni več char ampak je String? In pol kr naenkrat se urine vmes še StringBuffer!?! Moje vprašanje, zakaj sploh to rabmo? Zakaj je en znak char, dva in več očitno String in če želiš delat z njimi še StringBuffer. Kje se to sploh rabi? Pri spremenljivkah? Recimo stavek:
System.out.print ("danes je lep dan"); // ali so besedice "danes je lep dan" obravnavane kot String? Recimo da bi želel notri urivat, obračat, dodajat, chare kako bi potem to nardil?
whatever ::
Razred je recept za kreiranje objekta zelo poenostavljeno receno. Obstajajo namreč tudi razredi, ki jih ne moreš instancirati. Znotraj razreda lahko definiraš še žival, ki ji rečemo konstruktor in ji posreduješ ob kreiranja objekta z new imerazreda(); parametre, s katerimi naj se objekt tega razreda kreira. Ključna beseda static, s katero se boš kmalu srečal in s katero se boš kasneje srečeval še pogosteje, pa nam pove, kateri atribut znotraj nekega razreda je enak za vse objekte tega razreda. Če je z besedo static definirana funkcija, pomeni, da lahko to funkcijo kličeš direktno iz tega razreda, ne da bi moral prej ta razred instancirati. Zato famozni public static void main(), ker sicer bi moral razred, v katerem je metoda main() najprej instancirati in nato klicati metodo main. Bodi vesel, da imaš razrede kot so String, Stringbuffer ipd., saj so namenjeni zato, da delo z znakovnimi nizi precej olajšajo.
Veliko jih je notri, še več jih je pa zunaj.
Bilijarde v šole! - Ivan Kramberger
Abnormal behaviour of abnormal brain makes me normal.
Bilijarde v šole! - Ivan Kramberger
Abnormal behaviour of abnormal brain makes me normal.
]Fusion[ ::
No še eno smešno vprašanje. Čemu pol razredi? Recimo za primer spet MSN
Ena izmed prednosti je ponovna uporaba. Recimo razred, ki ga boš uporabljal za pošiljanje texta drugemu računalniku lahko uporabiš v kakem drugem programu brez da funkcije kopiraš.
A to zahteva 3 razrede al kako? Lahko vse 3 združiš v 1 razred?
Ne samo da lahko daš vse v en razred, če ti paše lahko vse strpaš v Main() funkcijo.
Kje pa veš da moreš postaviti main metodo?
Postaviš v razred kjer ti paše. Večinoma pa se naredi posebaj razred za Main().
Pa še tole me bega v Javi imamo primitivni tipe, med drugim tudi char, ki predstavlja eno črko/znak npr. ´a´! Potem lahko spišemo več teh črk npr. ´anja´ in to ni več char ampak je String? In pol kr naenkrat se urine vmes še StringBuffer!?! Moje vprašanje, zakaj sploh to rabmo? Zakaj je en znak char, dva in več očitno String in če želiš delat z njimi še StringBuffer. Kje se to sploh rabi? Pri spremenljivkah?
Jah String je zanimiva stvar ker je tak da vsakič ko ti napišeš nekaj med "" se odzadaj naredi nov String objekt. Enako je ko ti delaš nekaj z "lalal" + "lalal". StringBuffer ipd. zadeve pa imajo dadatne funkcionalnosti, ki jih boš mogoče kdaj potreboval. Najboljše če si pogledaš Java API
System.out.print ("danes je lep dan"); // ali so besedice "danes je lep dan" obravnavane kot String? Recimo da bi želel notri urivat, obračat, dodajat, chare kako bi potem to nardil?
Jap je String. Če hočeš dodajat enostavno narediš +. Recimo: "danes je lep dan" + "ju3 bo tudi". Za vrivanje ipd. zadeve pa imaš funkcije, ki jih ima String razred.
Ena izmed prednosti je ponovna uporaba. Recimo razred, ki ga boš uporabljal za pošiljanje texta drugemu računalniku lahko uporabiš v kakem drugem programu brez da funkcije kopiraš.
A to zahteva 3 razrede al kako? Lahko vse 3 združiš v 1 razred?
Ne samo da lahko daš vse v en razred, če ti paše lahko vse strpaš v Main() funkcijo.
Kje pa veš da moreš postaviti main metodo?
Postaviš v razred kjer ti paše. Večinoma pa se naredi posebaj razred za Main().
Pa še tole me bega v Javi imamo primitivni tipe, med drugim tudi char, ki predstavlja eno črko/znak npr. ´a´! Potem lahko spišemo več teh črk npr. ´anja´ in to ni več char ampak je String? In pol kr naenkrat se urine vmes še StringBuffer!?! Moje vprašanje, zakaj sploh to rabmo? Zakaj je en znak char, dva in več očitno String in če želiš delat z njimi še StringBuffer. Kje se to sploh rabi? Pri spremenljivkah?
Jah String je zanimiva stvar ker je tak da vsakič ko ti napišeš nekaj med "" se odzadaj naredi nov String objekt. Enako je ko ti delaš nekaj z "lalal" + "lalal". StringBuffer ipd. zadeve pa imajo dadatne funkcionalnosti, ki jih boš mogoče kdaj potreboval. Najboljše če si pogledaš Java API
System.out.print ("danes je lep dan"); // ali so besedice "danes je lep dan" obravnavane kot String? Recimo da bi želel notri urivat, obračat, dodajat, chare kako bi potem to nardil?
Jap je String. Če hočeš dodajat enostavno narediš +. Recimo: "danes je lep dan" + "ju3 bo tudi". Za vrivanje ipd. zadeve pa imaš funkcije, ki jih ima String razred.
"I am not an animal! I am a human being! I... am... a man!" - John Merrick
]Fusion[ ::
V principu te nobeden ne sili da pišeš 1000 razredov in da delaš z interface-i, dedovanjem, statičnimi metodami in atributi... Lahko vse narediš v en razred, maš vse globalno in to je to. Samo je res da to niso dobre prakse. Sicer pa boš s časom ko boš spoznaval JAVA API moral vedet za te zadeve drugače se boš čisto zgubil v njem 
.
. "I am not an animal! I am a human being! I... am... a man!" - John Merrick
Voyager ::
Razred v splošnem ne more biti private (izjema je podrazred oz. razred vgnezden v nek drug razred).
Lažje je razložiti če vprašaš kakšna je razlika med private in public spremenljivkami in metodami. Spremenljivke in metode, ki so označene kot private so vidne le tistemu razredu v katerem se nahajajo. Drugi razredi do takih spremenljivk in metod nimajo dostopa. Če pa so spremenljivke in metode public, pa so vidne tudi drugim razredom.
Kot rečeno, malce drugače je če gledaš pomen private/public v primeru dveh razredov pri katerih je en podrazred drugega. Ampak mogoče za osnovno razumevanje naj bo zgornje dovolj, če ne pa vpraši.
Lažje je razložiti če vprašaš kakšna je razlika med private in public spremenljivkami in metodami. Spremenljivke in metode, ki so označene kot private so vidne le tistemu razredu v katerem se nahajajo. Drugi razredi do takih spremenljivk in metod nimajo dostopa. Če pa so spremenljivke in metode public, pa so vidne tudi drugim razredom.
Kot rečeno, malce drugače je če gledaš pomen private/public v primeru dveh razredov pri katerih je en podrazred drugega. Ampak mogoče za osnovno razumevanje naj bo zgornje dovolj, če ne pa vpraši.
Vredno ogleda ...
| Tema | Ogledi | Zadnje sporočilo | |
|---|---|---|---|
| Tema | Ogledi | Zadnje sporočilo | |
| » | PHP in objektno programiranje (strani: 1 2 )Oddelek: Programiranje | 11297 (9764) | kivi113 |
| » | Java program (strani: 1 2 )Oddelek: Programiranje | 7913 (7062) | kunigunda |
| » | Kaj, kako se učiti?Oddelek: Programiranje | 2457 (1933) | napsy |
| » | PHP OOPOddelek: Izdelava spletišč | 2127 (1598) | Pegaz |
| » | osnove v Javi - zvezdiceOddelek: Programiranje | 3388 (2610) | Tutankhamun |