Hirdetés

Keresés

Új hozzászólás Aktív témák

  • floatr
    veterán

    Köszönöm a segítséget! :R
    Most már működik amit szerettem volna, már csak egy kérdés: ha egy static metódusban akarnám ezt alkalmazni, akkor ugye a getClass() nem játszik csak így magába, ilyen esetben ezt érdemes használni: [aktuális_osztály_neve].class ? Mert én így csináltam és működött, csak az érdekel hogy más helyeken is ezzel találkozhatok-e majd?

    A getClass() egy metódus, amit akkor tudsz használni, ha van egy példányod futás időben. Pl előszedsz valahonnét egy ismeretlen típusú objektumot, és meghívod ezt a metódust, akkor a runtime viszaadja a típusához kapcsolt metaadatokat. A .class egy operátor, és a fordító fogja feloldani a dolgot

    Egy szemléletes példa:

    ...
    Object o = cacheMap.get(id);
    if (o != null && o.getClass().equals(User.class)) {
    User u = (User) o;
    ...
    }

  • F1rstK1nq
    aktív tag

    Köszönöm a segítséget! :R
    Most már működik amit szerettem volna, már csak egy kérdés: ha egy static metódusban akarnám ezt alkalmazni, akkor ugye a getClass() nem játszik csak így magába, ilyen esetben ezt érdemes használni: [aktuális_osztály_neve].class ? Mert én így csináltam és működött, csak az érdekel hogy más helyeken is ezzel találkozhatok-e majd?

    Gondolom a static main() metódusban használod.
    Igen amit mondasz, ebben az esetben teljesen jó. :K AktualisOsztaly.class a getClass() helyett.

    Kevés az esélye, hogy ezt egy static metódusban fogod használni real life projectben, bár ki tudja.

  • F1rstK1nq
    aktív tag

    Sziasztok!
    Gyakorolgatok éppen, és azt szeretném megtanulni, hogy a getResource() függvény segítségével hogyan érjek el ilyen forrásállományokat, és azokat kezelni tudjam a programjaim segítségével.
    A problémát igazából most az okozza, hogy rengeteg féle-fajta megoldást találok a neten, nem tudom melyik lenne a jobb, plusz sajnos még egyiket se sikerült megvalósítanom :(
    De most ne is ragadjunk meg egy konkrét kódrészletnél, inkább elmondom mit szeretnék.
    Konkrétan egy Maven projektet hoztam létre, van benne két mappa amit használnék, az src/main/java, ugye ide mennének az osztályaim, és az src/main/resources, ide pedig a forrásállományok. A forrásállományok mappájába létrehoztam egy sima szöveges fájlt, res01.res névvel, írtam bele 3 sort, ezt szeretném majd kiolvasni egy megírt osztály segítségével.
    És akkor ami a kérdésem lenne, mi erre a legelterjedtebb módszer, illetve amit még nem értek, hogy a getResource() függvénynek milyen logika alapján kell megadni az elérési útvonalat?
    Ha valaki saját választ ír azt nagyon megköszönöm, de ha linkeltek valami jó tutorialt nekem az is megfelel.
    Előre is köszi! :)

    Ez a klasszikus megoldás:

    String fileName = "res01.res";
    ClassLoader classLoader = getClass().getClassLoader();
    URL resource = classLoader.getResource(fileName);
    if (resource != null) {
    File file = new File(resource.getFile());
    try (BufferedReader br = new BufferedReader(new FileReader(file))) {

    String line;
    while ((line = br.readLine()) != null) {
    System.out.println(line);
    }
    } catch (IOException e) {
    e.printStackTrace();
    }
    }

    Viszont, ha érdekel más módszer is, itt még tudsz csemegézni Java8-as megoldások közül is. Viszont amit ezekben a megoldásokban nem látsz, hogy hogyan éred el a resources alatti fájlokat. Így:
    ClassLoader classLoader = getClass().getClassLoader();
    URL resource = classLoader.getResource(fileName);

  • caindwan
    aktív tag

    Először én is azzal kezdtem a Java tanulást, de szerintem egy kicsit erős kezdőknek, most nyáron elkezdtem olvasni az Agyhullám - Java című könyvet, ez nagyon jó!
    Kicsit lazább hangvételű könyv, vannak benne poénok is, életszerű példák, a leckék végén gyakorlatok és hozzájuk tartozó megoldások.
    Csak ajánlani tudom :K

    Nekem az a konyv nagyon bejott, szamomra erthetoen fogalmazott.
    @WonderCsabo: :C :C Az jo regeny!
    @raggg: legalabb gyakorlom az angolt :DD

  • Szmeby
    tag

    Persze hogy olvastam, meg csináltam is őket, csak én azt hittem hogy ez a csomagon kívüli valami speciálisabb dolog, de most már értem mire gondolt, köszi a segítséget! :D

    Ha biztosra akarsz menni, akkor a default package-be teszed.

    Ami ugye azt jelenti, hogy az osztály a classpath gyökerébe kerül, és elhagyod az osztály első sorában a package sort.
    Habár szerintem is a sereg csomagon kívüliségre gondolt, de furán fogalmaz, az biztos. Ha úgy érzed valami speciális illene ide, akkor csak a default package marad. Ki tudja, lehet, hogy előadáson így nevezte a default package-et. Ha így lenne, de te nem így csináltad, akkor viszont mehetsz reklamálni, mert azt nem úgy hívják és különben is odaírhatta volna, hogy pontosan mire gondol.

  • -v-
    addikt

    Ezt a zh feladatsort találtam meg még múltkor, és az A változatot néztem, abban van ez, a 4. feladatban.
    [Feladat]

    És a többi feladatot is elolvastad előtte? :P Mert akkor elég egyértelmű:
    Írj egy (a sereg) csomagon kívüli futtatható osztályt!
    Futtatható: van benne main ... de ez is elég egyértelmű a feladatból.

  • Szmeby
    tag

    A csomagon kívüli futtatható osztály mit jelent?

    Az osztályokat csomagokba rendezzük, arról gondolom már volt szó. Bizonyára valamilyen csomagban lévő osztályról beszél (pl.: com.dave.proba.MyClass), és most az idézeted egy az adott csomagon kívül eső osztályra tér rá (pl.: com.dave.MyOtherClass).

    Egy osztályt futtathatónak nevezhetünk, ha van pl. main metódusa. De a "futtatható" szó akár a Runnable interfészre is vonatkozhat, ami a szálkezelésnél jön elő, és teljesen mást takar.
    Amúgy nem tudom, ennyi információból nem lehet megmondani, max találgatni.
    Szerintem ne várj érdemi választ egy kontextusból kiragadott mondatra, akarom mondani 4 szóra.

    Valószínűleg többre mennél a könyv eredeti (angol nyelvű) változatával. Bár nem olvastam még, de sajnos az a tapasztalat, hogy előszeretettel fordítanak le MINDENT (igen, a keyword-öket is) elcseszett magyar kifejezésekre, így totálisan érthetetlenné téve a szöveget. Persze az is lehet, hogy csak nekem tűnik érthetetlennek, mert én az angol neveken szocializálódtam. Sose hívnám az interfészt pl. felületnek. És ez még a megbocsátható elfordítások közé tartozik. Borzasztó miket ki nem találnak.

  • emvy
    félisten

    Sziasztok!
    Korábban már volt egy kis Java ismeretem, de most nyáron jobban belemélyültem a dologba, éppen az öröklődésnél és az osztályoknál járok. Mindent értek, találtam egy kis dolgot, ami nem tiszta.
    A könyv amit olvasok (Agyhullám - Java) azt írja, hogy "A privát tagok nem öröklődnek."
    Én írtam egy A osztályt, aminek van egy int típusú privát tagja, és ezt el lehet érni és módosítani két publikus metódus segítségével. Aztán csináltam egy B osztályt, ami az A-t bővíti.
    Létrehozok egy B objektumot, de ugye a B objektumnál is meg tudom hívni az elérő és módosító metódusokat, tehát a B mégis rendelkezik azokkal az adattagokkal?
    Vagy ez azért működik, mert a B típusú objektum közben egy A objektum is (tehát a többalakúság miatt)?
    Vagy hogy lehet a legjobban értelmezni ezt a mondatot?

    A privat adattagok oroklodnek, de nem lathatoak. Azert nem jo kifejezes a 'nem oroklodnek', mert memoriat foglalnak, inicializalod(hat)nak, satobbi.

  • MrSealRD
    veterán

    Rendben köszi, csak amikor ezt a sort olvastam, azt hittem hogy ebben az esetben a leszármazott osztálynak nem is lesz olyan adattagja, bár annak meg mi értelme lenne :DDD

    A kérdés ennél kicsit bonyolultabb.

    Itt érdemes megnézni a Private Members in a Superclass című részt.

    Tehát az alosztály nem örökli az ősosztály privát tagjait. Azonban ha ezekhez a tagokhoz az ősosztályban írsz public vagy protected metódusokat akkor az alosztály ezáltal hozzáférést kap az ősosztály privát adattagjához...

    Ezt egyébként gyakorlati úton is lehet bizonyítani.:
    Ha a ClassA-t átírod az alábbi kódban a saját osztályaid nevére, akkor ez kiírja az adott osztály adattagjait. Ez a kód amúgy a stackoverflow-ról van. Van ott pár érdekes kérdés erről a témáról.
    Szóval ha lefuttatod akkor látni fogod, hogy az ősosztályodra listázni fogja az adattagokat, de a belőle származó alosztály esetében nem fog megjelenni a listában az ősosztály private adattagjai.

    public static void main(String[] args) {
    inspect(ClassA.class);
    }


    static <T> void inspect(Class<T> klazz) {
    Field[] fields = klazz.getDeclaredFields();
    System.out.printf("%d fields:%n", fields.length);
    for (Field field : fields) {
    System.out.printf("%s %s %s%n",
    Modifier.toString(field.getModifiers()),
    field.getType().getSimpleName(),
    field.getName()
    );
    }
    }

    De olvastam olyat is ahol azt írták, hogy inkább azt modjuk örökli, de nincs hozzáférése... :U

  • MrSealRD
    veterán

    Sziasztok!
    Korábban már volt egy kis Java ismeretem, de most nyáron jobban belemélyültem a dologba, éppen az öröklődésnél és az osztályoknál járok. Mindent értek, találtam egy kis dolgot, ami nem tiszta.
    A könyv amit olvasok (Agyhullám - Java) azt írja, hogy "A privát tagok nem öröklődnek."
    Én írtam egy A osztályt, aminek van egy int típusú privát tagja, és ezt el lehet érni és módosítani két publikus metódus segítségével. Aztán csináltam egy B osztályt, ami az A-t bővíti.
    Létrehozok egy B objektumot, de ugye a B objektumnál is meg tudom hívni az elérő és módosító metódusokat, tehát a B mégis rendelkezik azokkal az adattagokkal?
    Vagy ez azért működik, mert a B típusú objektum közben egy A objektum is (tehát a többalakúság miatt)?
    Vagy hogy lehet a legjobban értelmezni ezt a mondatot?

    Az A osztályodban az adattag private, de a hozzá tartozó getter & setter public. Ezért azok bárhonnan láthatóak. Ez így van jól.

    Ha csinálsz egy public adattagot az A osztályban akkor látni fogod, hogy B osztályban el tudod érni getter & setter nélkül... Ez mondjuk nem túl egészséges...de ha tovább olvasol majd meglátod.

    A getter & setter lényege pont az, hogy ellenőrzött módon tudj az adattagokhoz hozzáférni...

  • Davs
    tag

    Ha egy osztályt készítünk, akkor abban miért szokás felülírni az örökölt toString() metódust? Nézegettem forráskódokat a neten, és elég sok helyen vettem ezt észre.

    class MyClass {
    public MyClass {} // constructor

    public String toString() {
    return "Hello en vagyok az, MyClass" ;
    }

    public static void main(..) {
    System.out.println(new MyClass()) ; //Hello, en vagyok az, MyClass
    }

    }

    Magyarul "ki tudod iratni az objektumot" .

  • TBG
    senior tag

    Hát pascal, php meg c++ de ezeknek a legmélyebb részeit még nem érintettem.

    c++ - ban van interface, de az kicsit más. Inkább a java abstract-ra hajaz, ha jól emléxem. Illetve elveiben ugyanaz csak az implementáció más.

  • TBG
    senior tag

    Köszönöm a gyors válaszokat. Még nem teljesen értem, de már kezdem kapizsgálni. Ha elérek a könyvbe ehhez a fejezetben biztos miden tiszta lesz.
    Még egyszer köszönöm :R

    Van bámilyen más programnyelvből előképzettséged? Lehet, hogy egy ismert nyelven keresztül egyszerűbb lenne megérteni :)

  • modder
    aktív tag

    Még csak nemrég kezdtem el tanulgatni a Java nyelvet, de a tankönyv, amit olvasok már többször említette az "interfész" szót, és ezt is: "az osztály által implementált interfészek".
    Később persze ezt is tárgyalja majd a könyv, de már nagyon kíváncsi vagyok rá, beleolvasni meg inkább nem akarok előre.
    Csak egy rövid összefoglalóként mégis, mik ezek az interfészek, mire jók, és mit jelent az hogy egy osztály implementál egy interfészt?

    Ha már a könyvben szó esett arról, hogy "az osztály implementálja az x interfészt", akkor gyanítom, hogy egy valós példa is szerepel az interfész alkalmazására.

    Többek között azért jó egy interfész, mert elrejti az osztály konkrét implementációját (fordítási időben).

    Egy egyszerű példa a Swing ActionListener interfész amit arra használhatsz, hogy gui eseményekre (pl. gomb megnyomása) valamit reagáljon a programod.
    A GUI komponens .addActionListener( ActionListener listener ) metódusának egy olyan objektumra van szüksége, aminek van actionPerformed( ActionEvent e ) metódusa. Tehát létrehoztak neki egy interfészt, amiben deklarálták ezt a metódust, ez lett az ActionListener interfész. Ezzel kényszerítik ki, hogy csak olyan objektumot adjál át ennek a metódusnak, aminek megvan a megfelelő actionPerformed( ActionEvent e ) metódusa.

    Vissza a fordítási időhöz: Látható, hogy a Swing készítőket nem érdekli, hogy miután lefordították a Swing library-t milyen ActionListener objektumokat fog létrehozni a fejlesztő, lehet azoknak az objektumoknak hatszáz másik metódusa is, és mindegy, hogy mit csinál. Ami a fontos, hogy a fejlesztő által létrehozott listener objektumoknak meglesz az elvárható tulajdonsága: lesz neki actionPerformed( ActionEvent e ) metódusa.

  • Davs
    tag

    Még csak nemrég kezdtem el tanulgatni a Java nyelvet, de a tankönyv, amit olvasok már többször említette az "interfész" szót, és ezt is: "az osztály által implementált interfészek".
    Később persze ezt is tárgyalja majd a könyv, de már nagyon kíváncsi vagyok rá, beleolvasni meg inkább nem akarok előre.
    Csak egy rövid összefoglalóként mégis, mik ezek az interfészek, mire jók, és mit jelent az hogy egy osztály implementál egy interfészt?

    Egy intefesz csak definialja a metodusok neveit. Ha az osztalyod implementalja az interfesz, akkor az osztalynak definialnia kell MINDEN metodust, ami az interfeszben volt. Ahogy az elottel szolo peldajaban is latod, a MyService interfeszben csak a metodusok neve van definialva. A MyServiceImpl osztaly implementalja a MyService interfeszt, ezert implementalnia kell a get/setSomething metodusokat.

    Ez ez egesz iterfeszes dolog pl arra jo, hogy ellenorizni tudod, hogy egy osztaly implementalja-e az adott interfeszt, es ha igen, akkor biztosan tudod, hogy az osztaly tartalmazza az interfeszben definialt metodusokat stb.

  • TBG
    senior tag

    Még csak nemrég kezdtem el tanulgatni a Java nyelvet, de a tankönyv, amit olvasok már többször említette az "interfész" szót, és ezt is: "az osztály által implementált interfészek".
    Később persze ezt is tárgyalja majd a könyv, de már nagyon kíváncsi vagyok rá, beleolvasni meg inkább nem akarok előre.
    Csak egy rövid összefoglalóként mégis, mik ezek az interfészek, mire jók, és mit jelent az hogy egy osztály implementál egy interfészt?

    Pár szó akkor.

    Interfész:

    public interface MyService {

    public void setSomething();
    public String getSomething();

    }

    public class MyServiceImpl implements MyService {

    @Override
    public void setSomething(String something) {
    // Do something...
    }
    @Override
    public String getSomething() {
    return "Some String";
    }
    public void setFoo(String foo) {
    // Do anything else...
    }

    }

    public class Something {

    public static void main(String[] args) {

    // Ebben az esetben csak azokat a metódusokat látod, amiket a MyService interfész deklarál....
    MyService myService = new MyServiceImpl();
    myService.setSomething("Hehe");
    String something = myService.getSomething();

    // Ebben az esetben látod az interfész által deklarált metódusokat és az egyebeket is.
    MyServiceImpl myServiceImpl = new MyServiceImpl();
    myServiceImpl.setSomething("Hehe");
    String something = myServiceImpl.getSomething();
    myServiceImpl.setFoo("Foo");

    // Röviden...

    }

    }

  • MrSealRD
    veterán

    Még csak nemrég kezdtem el tanulgatni a Java nyelvet, de a tankönyv, amit olvasok már többször említette az "interfész" szót, és ezt is: "az osztály által implementált interfészek".
    Később persze ezt is tárgyalja majd a könyv, de már nagyon kíváncsi vagyok rá, beleolvasni meg inkább nem akarok előre.
    Csak egy rövid összefoglalóként mégis, mik ezek az interfészek, mire jók, és mit jelent az hogy egy osztály implementál egy interfészt?

    Türelem...Olvass tovább és akkor tiszta lesz. Nem véletlen nem tart még ott a könyv, hogy ezt tárgyalja.

Új hozzászólás Aktív témák