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?

„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) interface

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.

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

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

A munkahelyemrõl szeretném elérni az otthoni gépemet, amellyen UHU fut.

Csináltam egy dyn.hu-s címet, de nem tudom, hogy hogyan tovább.

Próbálkoztam ezzel a vnc dologgal, de nem akart sikerülni.

Van másik módja is a távoli használatnak, vagy csak a vnc?

a gépemen fut egy jboss+ postgres szerver, ezeket szeretném elérni távolról Win XP alól.
[align=right][snapback]141664[/snapback][/align]

na 1 pillanat… 🙂 mit is szeretnél? bejelentkezni a munkahelyedrõl a saját gépedre? (mint normál user, etc, csak távolról?)
Ez esetben ajánlom, az ssh környékén nézz körül. Ha graf. bejelentkezést szeretnél, akkor meg rdesktop.

Ha „csak” simán a postgres/etc szervered szeretnéd elérni, akkor annyi a dolgod, hogy megnézed, ki van-e nyitva az adott szervernek megfelelõ portod a külvilág felé. (pl. routeren/tûzfalon kinyitod a postgres/etc szerverek portjait, és aztán már el tudod õket érni távolról)

kl223

1. ha a modul meg akarja védeni az adatait a putModuleData() -ban (ami így nyugodtan lehet interface) egy olyan objektumot is átadhatna amiben az adatok hozzáférése private, így hiába szerzi meg akárki az objektumot az adatokhoz nem fér hozzá

Naigen, de akkor maga a modul se férne hozzá a saját adataihoz, elvégre a private a modulnak is private! :blink: Persze megoldás lehetne, ha a modul egy saját statikus belsõ osztályát pakolja be, mert ekkor lehetnek a tagok private-ok, a modul hozzájuk fér, és más nem. Csakhogy ekkor ki kellene kötni, hogy csak belsõ osztályt pakolhat be a modul, és ha mondjuk egy Vectort/etc akarna bepakolni, akkor nehézkes lenne a megvalósítás.
Mind1.