- This topic has 41 hozzászólás, 5 résztvevő, and was last updated 6 years, 1 month telt el by
.
- Bejegyzés
Amúgy miért is kell ennyire túlbonyolítani, hogy az Objektum a Műveletosztály templatenek a leszármazottja. Különösen templateknél, amik futásidőben jönnek létre gondokat okozhatnak.Az alábbi két mód praktikusabb lenne:
Code:class Objektum {Ne haragudj, de nem igazán értem amit írsz. Ha a konkrét esetre vonatkoztatva írnál egy picit konkrétabb példát, lehet, hogy könnyebben felfognám.Most valami ilyent gyanítok a konkrét esetre, de eléggé nem tiszta:
Code:class Finder {Attól függ, hogy milyen műveleteket akarsz végrehajtani.Íme néhány példa.Ha csak kereső algoritmus kellene, akkor a tárolót egy tároló osztályból (List, Vector) származtatnám.Minden adott az elemek hozzáadásához, törléséhez stb.Record
Code:class Record {Persze pl. a Record lehet egy fő osztály, ami különböző típusú recordokat is tartalmazhat, vagy mint származtatott osztályokként, vagy egy pl. intben tárolt típusazonosító alapján. pl. MaleRecord extends Record, Female extends Record.// Male specifikus művelet
Code:class Male extends Record {public ... maleOp (...) {}}Ettől sokkal bonyolultabb lenne olyan tárolót csinálni, mely egyszerre többféle elemet képes tárolni.
Megrpóbáltam beazonosítani a Te fogalmaidat az enyémekkel, lehet, hogy nem sok sikerrel.Nálam van egy AR osztály, amiben implementálva lenne az adatbáziskeresés, és erre épülnek a konkrét táblákat kezelő aktív rekordok, mint például a UserRecord.Ha jól látom, az én AR osztályom helyett használod Te a
(Nem kell find osztályt létrehozni, lád pl. egy sztring tároló osztály összes függvénye… érdemes ezt tanulmányozni.Abszolút nem értem, hogy neked az ilyenek "UserRecord().findByPK(id)", miért "könnyebbek". A UserRecord keres a UserRecordok között? Ennek nincs értelme, hacsak nem a szándékos hibák /rögtön szálbiztonság dobása/ és átláthatatlanság kreálása. Persze ezzel a dinamikusságot és a rugalmasságot is csökkentetted, mert a UserRecord nem ismerheti a UserRecordokat, csak, ha egy darab statikus Lista van, vagy akkor, ha átadod a Listát. Az utóbbi a szálbiztosságot azonnal dobja, azon kívül baromira lassú is lehet átadni a Listát, ha rosszul van megírva... márpedig, ha nincs Lista kezelő objektumod (és tömböt adsz át), akkor bizony rosszul van megírva.)Neked a tároló és a tároló tartalma egy osztály, ami több problémát okoz.A templateknél tuti szívni fogsz, ha jól értelmezem szívni is fogsz. (Meg még ki tudja hol.)A Java sokkal kötöttebb, mint a C++ így egy bonsolultabb szerkezeteknél, a származtatásoknál szintén gond lehet.Ezen kívül átláthatatlanabb, mint egy szép hagyományos Java (sőt standard C++) struktúra, ezért nem szokás ilyet alkalmazni.Igen jól látod, a tároló struktúrát (származtatásokat) ajánlott az elemek struktúrájától külön definiálni. Sőt egy iterátort is. (Bár jelen esetben az utóbbival nem érdemes foglalkozni, mert van remek beépített.)A Java egy sokkal erősebben objektum orientált rendszer. Bár a C++ is ettől lesz struktúrált, átlátható. Ezek nem felesleges dolgok, erre van a rendszer kitalálva, ki kell használni. Sőt ilyen esetekben (kivéve természetesen a paraméteres műveleteket) még C-ben is érdemes objektumokat létrehozni. Java esetén a műveleti függvények is objektumok.Nézz meg bármilyen oo tárolót, mindenhol ilyet használnak. Vagyünk pl. egy sztringet, widget rendszert stb. (Java, std C, gobj, qt) mind így struktúrálja... valami oka csak van.Van egy előre definiált konténer (List, Vector, akármi), ebből származik a Record tárolód (pl. RecordList), minden kereső, összehasonlító függvényt ez tartalmaz, lásd a String-et, mely pl. karaktereket tárol. (Te a karakterek helyett Recordokat ill. Recordból származó osztályokat tárol.)
Code:class RecordList extends List {Rendben, egyelőre megpróbálom megérteni amit írsz:Mit keres itt a List? Azon kívül, hogy van egy ilyen tároló, mi köze az adatbáziskezeléshez?A lista elemeket tárol, de nekem csak 1 elem kell, épp amelyikkel dolgozni szeretnék. Miért kell egy elemhez tároló? Vagy az egész táblát kellene tárolnom listában? A listának valóban van kereső művelete, de ez a listában tárolt adatokban keres, ha jól tudom, és nem a táblában. Hogyan fog ez nekem keresni a táblában?(Arról nem is szólva, hogy hogyan keres egy lista majd egy összetett SQL kifejezéssel?)
Ha sql, akkor már lehet kicsit konkretizálni a dolgokat.Nem, az egymásra épülő objektum orientáltság miatt soha nem kell az egészet betölteni, hanem pl. kereshetsz a sor objektumokban, vagy épp az oszlop objektumokban, nem kell a teljes tartalmat beolvasni. (Az egymásra épülő objektumok, csak tárolók és még, ha be is olvasod a benne lévő adatokat, azok az adatok megint csak tárolók és a benne foglalt adatok nem olvasódnak feltétlenül be.) Sőt egy tartalom esetén is megadhatsz beolvasandó határértékeket. Az osztályokat pedig a fent említett módon kiegészítheted saját függvényeiddel.Természetesen vannak adatbáziskezelő függvények is a Javaban sőt szerencsére van sql Array interface is.valami ilyesmi pl.:Array arr = ResultSet.getArray(oszlopindex/cimke)String[] strings = (String[])arr.getArray()Természetesen az oszlopkereső függvény meg már implementálva is van (ha az kell): index = ResultSet.findColumn(cimke). Nyilván lehet bővíteni. Pl., ha azokat az indexeket szeretnéd megkapni, melyek azon stringtöredékekkel rendelkeznek
Code:class MyResultSet extends ResultSet{Azt hiszem, az oszlopokat hagyjuk, mert bár azt írod, hogy az oszlopokat nem kell betöteni mindet, a kereső mégiscsak szépen végigmegy az összes oszlopon, míg meg nem találja a keresettet, azaz a keresett értékeket be kell tölteni, ha nem is mindet, de a keresésig. Ez ugye nem indexelt keresés, számomra nem is fontos.A rekordok keresésére azonban nem tudom rávetíteni, mivel ott úgyis az sql fog keresni és nem én, nekem meg lesz 1 darab eredmény tömböm a mezőadatokkal.Emiatt akkor még mindig nem látom célját a tárolónak. Legalábbis a rekordokat tárolóba nem tenném. A mezők persze tárolóban vannak.Majd persze lesz olyan művelet, ami több rekordot ad vissza, annak az eredménye természetesen tároló, de én egyelőre a findByPK() műveletet szeretném tisztázni, aminek az eredménye mindig 1 db rekord (vagy null).Itt lenne szükségem arra, hogy az eredmény különböző osztályú legyen. Például UserRecord, vagy ItemRecord, vagy bármi, ami AR leszármazott.
– A kérdésed az volt, hogy az egész táblát be kell tölteni, a válasz az, hogy nem. Nem pedig az, hogy semmit nem kell betölteni.- Azt amibe keresel, mindenkép be kell tölteni. Miért varázslatra talál meg a gép neked egy dolgot?- Egyébként azt mondtam, hogy az oo hierarchiára épült rendszer nem tölt be mindent egyszerre, hanem csak a memória címeket. Ha van egy Lista objektumod, az nem fogja tartalmazni a Lista Elemeit, hanem egy iterárort, egyéb függvényeket, mely léptet stb. Ettől függetlenül mozgatható az adathalmaz, adott esetben nem is kell a memóriában tartani, attól függ hogy van megírva.- A "findByPK"-nak objektumban kell lennie, mert ez Java. Teljesen mindegy, hogy oszlopnak, recordnak, tárolónak, művelet osztálynak nevezzük (meg oldjuk meg). Mivel úgyis használni kell az adatbázis interface-eket, a saját függvényeket értelmetlen is máshol definiálni (érdemes származtatni).- A "findByPK" nem "lehet" a rekordnak a függvénye, mert a visszatérési értéke a rekord. (Rekord nem kereshet a rekordokban, mert nem "látja" őket.) Az úgy egy logikátlan, komoly problémákat is okozhat. Pl. ne csodálkozz rajta, ha nem lesz szálbiztos/felülírsz valamit véletlenül, nem fordulnak le a templateid, vagy épp nem fér hozzá nem statikus változókhoz. Ez most nem gond, de később még lehet az.A ResultSet (a tábla "eredménye"), mely sorokból áll (nők adatai, férfiak adatai - amik származhatnak az adatokból pl.), melyekhez hozzá lehet adni, törölni lehet, (korlátozottan) keresni lehet, léptetni lehet és metaadatokat tartalmaz. Ez további adatokból áll, amit oszlopoknak hívunk, melyben a rendszer csak a cimkék szerint tud keresni.Ha te a rekordjaidban tárolsz egy nevet, címet, születési időt halálozási időt és ezekben is keresni szeretnél, vagy a cimkék között pl. "idő", akkor bizony saját függvényeket kell írni, mert nem fogja megkeresni neked a táblázatkereső, mert nem ez a feladata, nem univerzális.(Persze akár lehet feljebb is helyezni a szintet: lehetnek férfiak táblái, nők táblái, így már 3d-s az adatbázis. Persze, jelen példában ez hülyeség, de nem ez a lényeg. Meg persze, ha jól tudom Array és a ResultSet "korlátlanul" egymásba ágyazható. A ResultSet-nek van getArray, az Array-nek van getResultSet fügvénye.)Továbbá, ha nem tetszenek a Java függvények, akkor még mindig futtathatsz - elvileg - sql utasításokat (executeUpdate). Erre megírhatod a saját osztályaidat, függvényeidet. Nyilván sokkal testreszabottabb lesz, mint a Java kód.Nem akarom - végül is - ráderöltetni a már megírt beépített kódokat sem, meg ezt a - ha jól értem - róka-fogta csuka statikus definiálós elvetését sem, csak a véleményemet írtam le.
- Be kell jelentkezni a hozzászóláshoz.
legutóbbi hsz