- This topic has 54 hozzászólás, 15 résztvevő, and was last updated 18 years, 2 months telt el by
.
-
Bejegyzés
-
Csakhogy ez nem oldja meg a problémát (egyébként nem hiszem, hogy ez gond lenne, legalábbis nekem még nem jelentett soha akadályt) ugyanis az osztály hoz(hat) magával implementációt az interface pedig nem (ahogy te is írtad).
Rendben, megkísérlem részletesen elmondani. Namost rólam azt kell tudni, hogy amit én értek, azt nehezen tudom érthetõen elmagyarázni… 🙂 Szal ha vhol rosszul magyarázom, akkor pls. jelezd.
(Elõre annyit még, hogy elõször megpróbálom a gondolatmenetemet leírni, aztán egy második postban összefoglalva az egészet. Remélem, ez majd segíti a megértést valamennyire. Tudom, mennyire nehéz néha mások megoldásait megérteni )Nos, úgy néz ki a programom, hogy 3 modulból áll. (eirc_net, eirc_data és eirc_gui)
Ezeknek a moduloknak számos eljárást meg kell valósítaniuk, lényegében minden fontosabb eseményre reagálniuk kell. (pl. új csevegõpartner felvétele, vagy épp törlése, üzenet elküldése, vagy épp fogadása, szerverhez csatlakozás, etc…)
Ezek az „események” voltak az interfész részei, illetve ezek mostmár az õsosztály absztakt metódusai, amit minden modulnak kötelezõen meg kell valósítania implementáláskor.Természetesen mindegyik modulban van néhány eljárás, aminél az adott modul épp semmit nem csinál, de ez nem baj…
Továbbá létezik egy manager-osztály, ami egy singleton osztály, lényegében egy speciális modul (mivel ugyanúgy implementálja ezeket az eljárásokat) de ehhez az osztályhoz kell hozzáadni a többi modult, majd ennek az osztálynak az eljárásait hívogatni.
Hi!
Akkor valamiféle félig-java félig-algoritmus nyelven leírom a rendszer vázát. (az objectID objektum felépítését már nem, az ott van kompletten az elõzõ postomban)De ittvan az eirc_module (az õsosztály lényege):
Code:public abstract class eirc_module {// ————————————————————az elõre megírt részek
// ezzel az egyediség garantálva van. Továbbá, mivel ez private, még a leszármazottak
// sem láthatják. (azaz a majdani modul nem láthatja a saját azonosító-objektumát)
private final transient objectID oid = new objectID();
public final boolean checkID( objectID _id ) {
// itt összehasonlítjuk a kapott _id objektumot a saját oid objektumunkkal.
// (getID() metódus segítségével) és igazat adunk vissza, ha a két objektum egyenlõ.
}protected final java.io.Serializable getModuleData() {
// itt (az mgrModules-en keresztül, lsd késõbb) kikérjük a saját objektumunkat, és
// visszaadjuk.
}protected final void setModuleData( java.io.Serializable obj ) {
// itt ugyanaz, mint a getModuledata()-nál, csak nem kikérjük, hanem beállítjuk.
}// —————————————————————-az absztakt metódusok
public abstract String getModuleName();
public abstract void addServer( server _s );
public abstract void removeServer( server _s );
// …
public abstract void recvPM( server _s, String from, String to, String msg );
// … (rengeteg ien eljárás van, mindenféle eseményre van egy, ami csak létezik…;)} // public abstract class eirc_module
Ennyi. Minden modulnak ezt kell kiterjesztenie.
Ha pedig a modul hozzá akar férni az objektumához, akkor a saját get/setModuleData() eljárásait kell hívnia.
Ezután egy speciális modul jön, az mgrModules. Itt csak beidézem a kódot, elég érthetõ egyébként, de sok része nem is fontos számunkra.Code:public final class mgrModules extends eirc_module {
// ————————————————–singleton design pattern
private static mgrModules pinstance = null;
public synchronized static mgrModules Instance() {
if ( mgrModules.pinstance == null ) mgrModules.pinstance = new mgrModules();
return mgrModules.pinstance;
} // private synchronized static mgrModules Instance()
/** Creates a new instance of mgrModules */
private mgrModules() {
} // constructor
// ————————————————————————
// data storage
private java.util.Map modules = java.util.Collections.synchronizedMap( new java.util.Hashtable() );
// ——————————————————-module-management
public void addModule( eirc_module newmod ) {
this.modules.put( newmod.getModuleName(), newmod );
newmod.reinit();
} // public void addModule( eirc_module newmod )
public void removeModule( String name ) {
this.modules.remove( name );
} // public void removeModule( String name )
public boolean moduleExist( String name ) {
return this.modules.containsKey( name );
} // public boolean moduleExist( String name )
public eirc_module getModule( String name ) {
return (eirc_module)this.modules.get( name );
} // public Object getModule( String name )
// ———————————————-eirc_module implementation
// itt pedig minden hülye absztrakt metódust implementálunk, pl:public void addServer( server _s ) {
synchronized( modules ) {
for( java.util.Iterator it = modules.keySet().iterator(); it.hasNext(); ) {
((eirc_module)modules.get( (String)it.next() )).addServer( _s );
} // for
} // synchronized
} // public void addServer( server _s )// amint láccik, az összes hozzáadott modulnak továbbítjuk az eseményt. Ez az mgrModules
// osztály legfõbb feladata.// …
}
Még az eirc_data van hátra, abból is egy erõsen fogyókúráztatott verzió:Code:public final class eirc_data extends eirc_module implements java.io.Serializable {
// (ez az egyetlen szerializálható modul)
// a modulok adatai
private java.util.Map mod_data =
java.util.Collections.synchronizedMap( new java.util.Hashtable() );
// (és itt még jópár cucc van, ez a modul mindenféle dolgot tárol, nem csak ezt.
// Nem véletlenül lett ez szerializálható, ez tárolja a partnereket, a szervereket, etc.)
// ——————————————————-module management
public void registerModule( String _newmod, objectID _id ) throws IllegalArgumentException {
// Ezt kell meghívnia a modulnak mindenekelõtt, de az automatikus meghívás le
// van kezelve a getModuleData() és setModuleData() eljárásokban.// Csak a modul õsosztályban megírt része reggelheti be önmagát (mivel más nem ismeri a
// modul objectID objektumát.
}public boolean isModuleRegistered( String _mod ) {
return this.mod_data.containsKey( _mod );
} // public boolean isModuleRegistered( String _mod )
public void putModuleData( String _mod, objectID _id, java.io.Serializable _data )
throws IllegalArgumentException {// az mgrModules osztályból név alapján ki lehet kérni modulokat. A _mod
// változóban kapott nevû modult kikéri, majd annak checkID metódusával megnézi,
// hogy a kapott _id objektum valóban azé a modulé-e. Amennyiben igen,
// akkor végrehajtja a mûveletet, ha nem, kivételt dob.
}
public Object getModuleData( String _mod, objectID _id ) throws IllegalArgumentException {
// ugyanaz, mint a putModuleData eljárásban, csak itt kiveszi és visszaadja,
// amennyiben minden rendben.
}
// —————————————————–eirc_module implementation
// természetesen itt is implementáljuk az absztrakt metódusokat, ez itt nem lényeg.
} // public final class eirc_data extends eirc_module implements java.io.Serializable
Na ennyi. Hát nem gyönyörû?? 😉 😉 😉 😛
Ha vmi nem világos, és még érdekel a dolog, akkor szólj, és megpróbálom elmondani azt a részt.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á
2. nem tudom, hogy a getmoduledata milyen metódusokat hív, de ha public metoduson keresztül hozzá lehet férni az adatokhoz akkor a modult mi gátolja abban, hogy saját maga hívja meg ezeket (gondolom nem public csak nem látom a megvalósítást)
3. ha a modulok nem ugyan olyan sorrendben jönnek létre akkor hogy lesz azonos az idjük a korbábban mentettel??
hogy egy kis „hasznos” dolgot is mondjak:
return (x==5?true:false);
helyett return x == 5;és a singletont is meg lehet csinálni synhcornized kulcsszó nélkül
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.hmm… jobban belegondolva, télleg meg lehet valósítani synchronized nélkül, vhogy így:
Code:public class Singleton {private static Singleton pinstance = new Singleton();
public static Singleton getInstance() { return pinstance; }private Singleton() {}
}
hmm… jobban belegondolva, télleg meg lehet valósítani synchronized nélkül, vhogy így:
Code:public class Singleton {private static Singleton pinstance = new Singleton();
public static Singleton getInstance() { return pinstance; }private Singleton() {}
}
„Naigen, de akkor maga a modul se férne hozzá a saját adataihoz, elvégre a private a modulnak is private! :blink:”
nade a „saját magában” declarált private az neki azért csak elérhetõ, nem? 😉
” 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. „
valahogy így, csak nem kell, hogy statikus legyen, meg az sem, hogy belsõ 🙂
„A modult az gátolja meg abban, hogy ezeket maga hívja meg, hogy az eirc_data-beli metódusoknak szükségük van a modul objectID objektumára, amit maga a modul (azaz a leszármazott osztály) nem lát, mivel annak az õsosztályban private módosítója volt!”
ezt nem láttam, ok
„Egy kémmodul ugyan megadhatja a stringben egy másik modul nevét, de a másik modul objectID objektumát már nem tudja megszerezni!”
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
„Azaz minden indulásnál minden modul/etc új objectID objektumot kap.”
ahogy egy tanárom mondaná: Akkkkor eez így….. oké!
🙂„Hát kösz, hogy elolvastad eddig…. 🙂 nem gondoltam volna, h lesz olyan, akinek lesz türelme ehhez. Kíváncsi vok, hogy ehhez a posthoz volt-e még türelmed… 😆 „
volt, nope 🙂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)
gondoltam, hogy rájössz magadtól is 😉
ha nem használod az osztály nem biztos, hogy létrejön (a java specifikáció nem szabja meg, hogy induláskor inizializálni kell az osztályokat), amiket néztem jvm-ek (sun féle meg a creme) úgy mûködött, hogy csak, ha használtad az osztályt akkor inicializálta
[align=right][snapback]141674[/snapback][/align]kösz a bizalmat… B)
Legalább azt biztosan tudom, h nem nézel hülyének… 😉hja, de én nem szeretek függeni az adott java implementációtól… 🙂
meg úgy általában nem szeretek függeni különbözõ implementációktól/rendszerektõl.
Ezért (is) választottam anno a javat. 🙂Na, komolyra fordítva a szót: akkor nagyjából megvan, hogy mit miért csináltam a progimban úgy, ahogy? Végeredményben: megvan, hogy miért nem volt itt az interfész használható? (elvégre onnan indult ki az egész)
kl223
- Be kell jelentkezni a hozzászóláshoz.
legutóbbi hsz