- This topic has 54 hozzászólás, 15 résztvevő, and was last updated 18 years, 2 months telt el by
.
-
Bejegyzés
-
nade a „saját magában” declarált private az neki azért csak elérhetõ, nem? 😉
Najó, de épp az lenne a lényeg, hogy a modul ne saját magát pakolja be, hanem egy pici objektumot, ami tárolja minden adatát. Mivel egyetlen objektumot lehet bepakolni, ezért nyilván ha többmindent is akar a modul tárolni, akkor új osztályt kell erre a célra létrehoznia.
valahogy így, csak nem kell, hogy statikus legyen, meg az sem, hogy belsõ 🙂
Ha nem belsõ, akkor nem fog hozzáférni a private tagokhoz… 🙂 Ha meg írok neki vmi kikérõ fgv-t, akkor a kémmodul is kikérheti.
Ha pedig nem static, akkor egyetlen olyan objektum létezhet, és olyat még nem használtam… 🙂
(mert ugye ha a belsõ osztály static, akkor bármennyit létrehozhatok belõle, hozzáfér a szülõosztály az õ private tagjaihoz/etc, ha meg nem static, akkor egyetlen, a szülõvel speciális kapcsolatban lévõ belsõ objektum jön létre a belsõ osztályból)errõl jut eszembe a modulok hozzájuthatnak más modulok nevéhez?? ha igen nem lehet ezt elkerülni (esetleg egyszerûbben?) és akkkor máris megoldódott a probléma
Igen, van egy ien abstract metódus az õsosztályban, hogy „public String getModuleName()”.
De ez ugye azt ad vissza, amit akar.ja még az eredetihez annyit (elveszett az eredeti hozzászólásom), hogy az események megvalósítása miért nem a „standard” jól bevált módon megy? azaz regisztrálni kellene az eseményekre listener objektumokat és így elkerülhetõek lennének a nem implementált metódusok (és hivogatásuk)
[align=right][snapback]141675[/snapback][/align]hehe, ez eszembe se jutott…. talán azért akartam így, mert én a javanak ezt a megoldását nem szeretem! Nemtom, miért. Egyébként valóban, úgyis megoldható lett volna, de úgy én magam sem tudom áttekinteni…
kl223
kl223,2005. Jul. 18. – 11:18 wrote:„Najó, de épp az lenne a lényeg, hogy a modul ne saját magát pakolja be, hanem egy pici objektumot, ami tárolja minden adatát. Mivel egyetlen objektumot lehet bepakolni, ezért nyilván ha többmindent is akar a modul tárolni, akkor új osztályt kell erre a célra létrehoznia.”eddig én is így gondoltam
„Ha nem belsõ, akkor nem fog hozzáférni a private tagokhoz… 🙂 Ha meg írok neki vmi kikérõ fgv-t, akkor a kémmodul is kikérheti.”
igaz nem fogalmaztam elég érthetõen
ilyesmire gondoltam:
Code:package testa;public class Access {
public Access()
{
B b = new B();
b.pp = 0;
b.pro = 0;
}
}class B {
int pp = 1;
protected int pro =2;
private int pri = 3;}
itt nyilván nem lehet elérni B -t
Code:package testB;import testa.B;
public class Accesso {public Accesso()
{
B b = new B();
b.pp = 0;
b.pro = 0;
}
}„Ha pedig nem static, akkor egyetlen olyan objektum létezhet, és olyat még nem használtam… 🙂
(mert ugye ha a belsõ osztály static, akkor bármennyit létrehozhatok belõle, hozzáfér a szülõosztály az õ private tagjaihoz/etc, ha meg nem static, akkor egyetlen, a szülõvel speciális kapcsolatban lévõ belsõ objektum jön létre a belsõ osztályból)”ez most nem igazán értem…..
ha nem static akkor miért ne hozhatnál létre belõle többet??továbbra sem vagyok megyõzve, hogy ide nem kell (fõleg,hogy nem lehet) interface
ugyanis itt keverednek kicsit a dolgok, a modulnak kellene egy interface amiben a modul által megvalósítandó dolgoknak kell kerülnie, tehát ez a moduldata akármi akkor kerülne bele, ha a modulnak magának kéne errõl gondoskodnia (pl exit elõtt minden modulra meghívnád) ekkor nyilván nem lehet gond a „kémkedés” (vagyis nem ez a fajta)
ha nem így van, mint nálad is, akkor meg ez egy utiliti osztály igazából nem egy modul (nem kell impementálnia a modul interfacet) és van publikus metódusai amik tárolják az adatokat, és a modul „vigyáz” a saját adataira, ahogy itt éppen megbeszéljük, vagy te nyújtasz valami biztonsági mechanizmust (pl Object.getClass() vagyh Object.hashCode() felhasználásával)
„Ha nem belsõ, akkor nem fog hozzáférni a private tagokhoz… 🙂 Ha meg írok neki vmi kikérõ fgv-t, akkor a kémmodul is kikérheti.”
igaz nem fogalmaztam elég érthetõen
ilyesmire gondoltam:
……
Igen, magyarul azt akartad mondani, hogy a protected tagok az adott package-n belüli osztályoknak elérhetõek. Hja, de ekkor csak annyi a dolga a kémmodulnak, hogy magát egy csomagba pakolja a haxolni kívánt modullal és akkor hozzáfér.
Azt pedig nem tudom, hogy lehetne kikötni, hogy minden modul külön csomagban legyen…..
Bár biztosan van rá megoldás.
Bár ezt télleg jó lenne kideríteni, mert ugye a getModuledata()/putModuledata() is protected, és lehet, hogy ez a mizéria a csomagokkal ott is megvan…
Mondjuk ott elég lenne csak azt ellenõrizni, hogy ne kerülhessen modul az õsosztállyal egy csomagba, hiszen ezek a metódusok ott vannak.„Ha pedig nem static, akkor egyetlen olyan objektum létezhet, és olyat még nem használtam… 🙂
(mert ugye ha a belsõ osztály static, akkor bármennyit létrehozhatok belõle, hozzáfér a szülõosztály az õ private tagjaihoz/etc, ha meg nem static, akkor egyetlen, a szülõvel speciális kapcsolatban lévõ belsõ objektum jön létre a belsõ osztályból)”ez most nem igazán értem…..
ha nem static akkor miért ne hozhatnál létre belõle többet??
továbbra sem vagyok megyõzve, hogy ide nem kell (fõleg,hogy nem lehet) interfaceHát… most lehet, h én értelmeztem félre vmit, de nézz utána a „Kék Bibliában”. Ott ír vmi ilyesmit, hogy a belsõ osztályoknál ha static, akkor olyan, mintha mondjuk C++-ban friend belsõ osztály lenne, azonban a nem static belsõ osztály teljesen más. Nem-static belsõ osztálynál a burkolóosztály minden egyes példányához létrejön 1 db belsõ osztálybeli példány (auto) és ezek ugyancsak oanok, mintha c++os friend osztályok lennének.
ugyanis itt keverednek kicsit a dolgok, a modulnak kellene egy interface amiben a modul által megvalósítandó dolgoknak kell kerülnie, tehát ez a moduldata akármi akkor kerülne bele, ha a modulnak magának kéne errõl gondoskodnia (pl exit elõtt minden modulra meghívnád) ekkor nyilván nem lehet gond a „kémkedés” (vagyis nem ez a fajta)
hogy is gondolod? Lenne egy függvény a modul-interfészben, ami kikéri minden modultól a maga kis mentendõ objektumát?
De akkor mi a garancia, h nem a kémmodul kéri ki azt?
Nameg a szerializáció is sokkal nehézkesebb lenne: minden egyes szerializációnál körbe kéne járni minden modult, és kikérni tõle a kis pekkjét és kiírni/etc. Ráadásul visszatöltésnél lenne gáz, hogy milyen sorrendben írtam ki a modulok adatait? Mert ugye ha rossz sorrendben próbálom visszaolvasni, akkor szívás van.
Még nagyobb gáz, ha a legutóbbi szerializáció óta új modult adtam a rendszerhez/eltávolítottam egy régit… ajjjajajjj… rossz is belegondolni, mi mindenre kéne figyelni.Ellenben most a szerializáció 5 sor: kiírom az eirc_data modult, és kész. Visszaolvasásnál meg visszaolvasom, utána a többi modult létrehozom, és azok kiszedik az eirc_data-ból a maguk kis csomagjait, és minden visszaállt normálisba.
ha nem így van, mint nálad is, akkor meg ez egy utiliti osztály igazából nem egy modul (nem kell impementálnia a modul interfacet) és van publikus metódusai amik tárolják az adatokat, és a modul „vigyáz” a saját adataira, ahogy itt éppen megbeszéljük, vagy te nyújtasz valami biztonsági mechanizmust (pl Object.getClass() vagyh Object.hashCode() felhasználásával)
[align=right][snapback]141694[/snapback][/align]De így kényelmesebb, mert azzal, hogy modul is, meg van oldva az automatikus adat-karbantartás.
Mert ugye pl. addContact absztrakt metódusnál õ elmenti a partnert. vagy addServer metódusnál elmenti a szerver objektumát, amit a metódussal kapott, etc.
Ugyanez fordítva is: removeServer/removeAccount/etc-nél törli a tárolt objektumát.A többi modul pedig nem tesz iet, mert nem az a dolguk. Pillanatnyilag (a többi modul addServer/addContact/etc metódusaiban) lehet hogy felhasználják a kapott szerver/partner/etc objektumot, pl. az eirc_gui modul naplózásra/user értesítéseire/új ablakok megnyitására/etc de nem tárolják.
Márpedig a metódus elszáll, de a modul megmarad… és készségesen szolgátatja ki késõbb a különbözõ cuccokat, ha szükség van rájuk. (és van szükség rájuk, az eirc_data modul a legaktívabb alighanem az átlagos mûködés során)Nos, igen, a hashCode()/etc is jó lehetett volna nekem e helyett az objectID-s rendszer helyett, de az objectID már korábban megvolt nekem, más célokra is használom a progiban, így egyszerûbbnek tûnt picit bebiztosítani (pl. gondoskodni róla, h ne lehessen klónozni/etc) és ezt használni ide is.
kl223
„Hja, de ekkor csak annyi a dolga a kémmodulnak, hogy magát egy csomagba pakolja a haxolni kívánt modullal és akkor hozzáfér.”
jó, oké a belsõ osztály egy fokkal jobb, bár a serializált fájlt még így is bárki olvashatja és akkor az egész móka semmit nem ér :)))
„Bár ezt télleg jó lenne kideríteni, mert ugye a getModuledata()/putModuledata() is protected, és lehet, hogy ez a mizéria a csomagokkal ott is megvan…”
ugyanabból a csomagból bárki meghívhatja azokat a függvényeket
„Mondjuk ott elég lenne csak azt ellenõrizni, hogy ne kerülhessen modul az õsosztállyal egy csomagba, hiszen ezek a metódusok ott vannak.”
ezt nyugodtan megteheted (de az „én” módszeremnél is)
„Hát… most lehet, h én értelmeztem félre vmit, de nézz utána a „Kék Bibliában”. Ott ír vmi ilyesmit, hogy a belsõ osztályoknál ha static, akkor olyan, mintha mondjuk C++-ban friend belsõ osztály lenne, azonban a nem static belsõ osztály teljesen más. Nem-static belsõ osztálynál a burkolóosztály minden egyes példányához létrejön 1 db belsõ osztálybeli példány (auto) és ezek ugyancsak oanok, mintha c++os friend osztályok lennének.”
nem tudom c-ben mi a friend, de a javas része tévedés az biztos!
egyszer sem írja ki, hogy létrejött:
(nagyon helyesen, hiszen senki nem hozta létre a belsõ osztályt, automatikusan sem jött létre nyilván)Code:public class Access {private class B {
{
System.out.println(„létrejött”);
}
int pp = 1;
protected int pro = 2;
private int pri = 3;}
public Access() {
}public static void main(String args[])
{
Access a = new Access();
}
}„hogy is gondolod? Lenne egy függvény a modul-interfészben, ami kikéri minden modultól a maga kis mentendõ objektumát?
De akkor mi a garancia, h nem a kémmodul kéri ki azt?”az,hogy nem kikérné hanem mondaná a modulnak, hogy mentsél amit kell mert kilépés van
(persze csak tipp volt)„rossz is belegondolni, mi mindenre kéne figyelni.”
így is lehetne, bár ez megint a te általad javasolt eljárás kicsit másképp, de ilyenkor sem kellene a serializációval szórakozni elég pl egy vectort serializálni
„De így kényelmesebb, mert azzal, hogy modul is, meg van oldva az automatikus adat-karbantartás.
Mert ugye pl. addContact absztrakt metódusnál õ elmenti a partnert. vagy addServer metódusnál elmenti a szerver objektumát, amit a metódussal kapott, etc.
Ugyanez fordítva is: removeServer/removeAccount/etc-nél törli a tárolt objektumát.
„
ha jól értem ezek az eirc modul adatai, azok hogy jönnek most ide (mármint nyilván azzal is foglalkozni kell, de nem ott ahol a többi modul menti az adatait)? vagy én nem látok valamit…..„Nos, igen, a hashCode()/etc is jó lehetett volna nekem e helyett az objectID-s rendszer helyett, de az objectID már korábban megvolt nekem, más célokra is használom a progiban, így egyszerûbbnek tûnt picit bebiztosítani (pl. gondoskodni róla, h ne lehessen klónozni/etc) és ezt használni ide is.”
de akkor ez az egész nem kellett volna… (persze lehet úgy is használni, hogy az ID helyett a hasht használod de az lényegében tényleg ugyanez)
ezt nyugodtan megteheted (de az „én” módszeremnél is)
Hja, de a te módszerednél meg kell nézni, hogy egyetlen modul se legyen egy csomagban egyetlen másikkal sem. Nálam meg csak annyi kell, hogy az õsosztállyal ne legyen egyetlen modul se egy csomagban… 🙂 Azért ez jelentõsen kevesebb ellenõrzéssel jár.
nem tudom c-ben mi a friend, de a javas része tévedés az biztos!
…Ok, rendben, ez csak rémlett vhogyan, vagy nemtom. :blush: De akkor mi a különbség a static és a nem static belsõ osztály között? Mert arra viszont teljesen biztosan Mléxem, hogy van vmi különbség a kettõ között.
az,hogy nem kikérné hanem mondaná a modulnak, hogy mentsél amit kell mert kilépés van
(persze csak tipp volt)Jó, de a modul ugye hova mentsen? Minden modulnak külön konfigfájl?
„
Hja, de a te módszerednél meg kell nézni, hogy egyetlen modul se legyen egy csomagban egyetlen másikkal sem. Nálam meg csak annyi kell, hogy az õsosztállyal ne legyen egyetlen modul se egy csomagban… 🙂 Azért ez jelentõsen kevesebb ellenõrzéssel jár.”ok
„Ok, rendben, ez csak rémlett vhogyan, vagy nemtom. :blush: De akkor mi a különbség a static és a nem static belsõ osztály között?”
hja 🙂 , az hogy a static osztály létezik önmagában nem kell hozzá enclosing class (próbálj meg példányt létrehozni az enclosing classon kívülrõl egy nem static inner classból aztán majd meglátod mi a különbség 🙂 )
„Jó, de a modul ugye hova mentsen? Minden modulnak külön konfigfájl?
hja 🙂 , az hogy a static osztály létezik önmagában nem kell hozzá enclosing class (próbálj meg példányt létrehozni az enclosing classon kívülrõl egy nem static inner classból aztán majd meglátod mi a különbség 🙂 )
kösz, jó tudni ezt is… 🙂
„Jó, de a modul ugye hova mentsen? Minden modulnak külön konfigfájl?
„biztonsági hiba” alatt mit értesz??
(mert ugye a serializált adatokhoz bárki hozzáféhet :)))) )
[align=right][snapback]141828[/snapback][/align]jó, persze, de most a programon belüli adatokat értem ez alatt 🙂 szal progin belül akárki akármilyen modult/etc telepít, baj nem lehet belõle.
Mondjuk a jelszó alapból MD5-ölve kerül a konfigfájlba, de ez sokat nem jelent, mert ugye a szerver is MD5-ös jelszót kér, tehát az esetleges külsõ proginak nem kell tudnia a jelszót, csak annak az MD5 értékét.Amúgy én nem aggódok annyira amiatt, hogy a szerializált fájl olvasható lesz 🙂
Biztosan tudom, hogy láttam már vhol olyan szûrõt (streamet), ami titkosítja a rajta átmenõ adatokat. Megkeresem, egyszerûen az ObjectInputStream alá húzom, és annyi volt… 🙂kl223
Kicsit régi téma, de hátha valakit még érdekel.
Az én olvasatomban az öröklõdés (extends) és a megvalósítás (vagy kivitelezés, vagy mi) (implements) között a következõ a különbség:
Az extends egy õs osztályból származtat egy gyerek osztályt, úgy (természetesen), hogy az õs osztályhoz valami pluszt hozzáadva lesz meg a gyermek osztály. Tehát az extends lényegében (bizonyos szempontból) speciálisabbá teszi a gyereket az õshöz képest (az általánosítás ellentéte, de most nem jut eszembe a megfelelõ szó, mert szól a fülembe az a s**r baráttoközt :mellow:).
Tehát az öröklés arra való, hogy „egy családba” tartozó, de valamiben különbözõ dolgokat lehet létrehozni.
Az õs mondjuk az élõlény, ebbõl származhat a madár, az ember, meg pl a krokodil, de nem igazán származhat a helikopter.
A gép õsosztályból pl. viszont származhat a helikopter, a hajó, meg a repülõ is.Tehát a a madár ugye élõlény, de annál speciálisabb, mert tudjuk, hogy van szárnya, vagy mittudomén.
A megvalósítás (implements) csak a különbözõ dolgok képességeik alapján való csoportosítását szolgálja.
Mondjuk készítünk egy interface-t, ami „repülni_tudó_cuccok” névre hallgat, és arra szolgál, hogy a repülni tudó dolgokat felruházza a repülés képességével. Van benne pl egy „repül” metódus, ami persze üres.
Namármost, ilyen esetben a heikopter is, a madár is meg a repülõ is „vállalhatja” (implements), hogy õ bizony megvalósít magában egy „repül” metódust, hiszen ezek tudnak repülni. Mivel mindegyik másképp repül, ezért minden osztály maga valósítja meg, hogy hogyan repül, a „közös helyen” (pl az õsben) ezt nem lehet (nincs is közös õsük).A SUN-os Java tanfolyamról ez maradt meg bennem, én így magyaráztam meg magamnak :poketoungeb:.
- Be kell jelentkezni a hozzászóláshoz.
legutóbbi hsz