Új hozzászólás Aktív témák
-
Aethelstone
addikt
Nos, hogy konkrét legyek.
Első körben a különféle táblákból szerver oldalon összerakjuk tárolt eljárásokkal a CSV-nek megfelelő táblákat. Aztán sima JDBC-vel végigiterálunk az összerakott táblákon és elkészülnek a CSV-k.
Miért nem szerver oldalon? Azért, mert nincs hozzáférésünk a szerver oldali fájlrendszerhez.
Ez kb. 10 query-t jelent, mindenféle JOIN meg hasonlók nélkül, csak SELECT x,y,z FROM d;Én nem lázadok a Hibernate vagy bármilyen ORM réteg ellen, csak ha nem indokolja semmi a használatát, akkor nem használom. Ennyi
[ Szerkesztve ]
MI 10T Pro 8/256 , Arsenal FC - Go Gunnarz...
-
Szmeby
tag
válasz Aethelstone #7997 üzenetére
Bocs, hogy én is felhozom, csak szeretnék rávilágítani a különbségre.
Az, hogy mindkét esetben láncban hívogatjuk a metódusokat, csak egy aspektusa a problémának. Valaki korábban említette, hogy pusztán a metódusok láncban hívása az un. "Law of Demeter" megsértése. Én ugyan nem nevezném törvénynek, de nem tényleg ajánlanám. Annak ellenére, hogy nekem is sokszor rááll a kezem.
Viszont a builder pattern ettől gyökeresen különbözik, és ezért "veszélytelen". Leginkább abban tér el, hogy a Builder mindig ugyanazon az objektumon dolgozik, a metódusok ugyanazzal a típussal térnek vissza. Egy nem builder esetén viszont ez korántsincs így, a hívó nem ismeri, nem ismerheti azt az osztályt, amit egy metódushívás visszaad, amit pedig annak a metódusa adna vissza, azt mégúgyse, és így tovább. Persze lehet szeretni, meg használni, legrosszabb esetben megtanulod a magad kárán.
-
Aethelstone
addikt
Ez igaz, de sok esetben nincs veszélye. Tipikus példa a konténer(DTO) jellegű osztályok.
Ha egymásba vannak ágyazva és engem csak egy érték érdekel, mondjukmyDTO.getSzamlak().getTetelek(0).getValue();
Itt ugye lehetne, hogy a getTetelek(0) esetén egy Tetel objektumot kvázi kiemelek és a getValue() metódust ezen hívogatom a jövőben, amennyiben többször is szükségem van az értékére. Vagy a fent írt sort idézgetem annyiszor, amennyiszer szükségem van rá.
Teljesítmény szempontjából semmiféle hátránya nincs, ha nem emelem ki, viszont megspórolok egy plusz objektumhivatkozást. Nyilván ha egy metódust drága hívogatni, akkor kiemelem, de pusztán annyit próbálok én is már ezer+1 hozzászóláson keresztül magyarázni, hogy a láncban hívás alapvetően lehet jó is. Feladatfüggő.
Nyilván ha nem tudom, hogy pontosan mit csinál a lánc, akkor tartózkodom a használatától, de ismétlem önmagam, a láncolt hívások alapvetően nem az ördögtől valóak és csak azért, mert nemteccik, nem kell elvetni a használatát.Law of Demeter, ha nem akarja egy objektum, hogy ilyen módon hívogassam a metódusait, akkor szervezze már úgy, hogy ne férjek hozzá, ha meg nem szervezi úgy és public, akkor miért ne használjam?
Ennyi. Zárom.
[ Szerkesztve ]
MI 10T Pro 8/256 , Arsenal FC - Go Gunnarz...
-
Sk8erPeter
nagyúr
válasz Aethelstone #8003 üzenetére
Viszont gyorsabbá teszi a debuggolást, ha változóba van kirakva, amikor odateszed a breakpöttyöt. (Már szinte várom előre is a "dehülyevagy-hádeménemdebuggolsz rendesen, az Expressions fület használva, meg mé' nem használod a Ctrl+Shift+D-t Eclipse-ben, a megfelelő kifejezést kijelölve", meg hasonló okosságokat. )
Sk8erPeter
-
Aethelstone
addikt
válasz Sk8erPeter #8004 üzenetére
Debug? Úri huncutkodás, az igazi programozó jó kódot ír Viccet félretéve, igazad van
MI 10T Pro 8/256 , Arsenal FC - Go Gunnarz...
-
MODERÁTOR
válasz Sk8erPeter #8004 üzenetére
Eclipse debuggere? Ne vicceljünk már! Idea!
"Ott szimatol a sarkadban vasfogait csattogtatva, minden egyes hétköznapod: kirúzsozott medvecsapda."
-
M_AND_Ms
addikt
válasz Aethelstone #8005 üzenetére
Nevetni fogsz! Én beszéltem (évek) óta programozóval, aki teljes természetességgel mondta, nem szokott debugolni.
Aki tejszínhabot szeretne, az inkább verje ki a fejéből!
-
ToMmY_hun
senior tag
válasz Aethelstone #7997 üzenetére
Ez nem egyéni preferencia kérdése. Letárolva jobban olvasható, gyorsabb és szebb. Nincs miről beszélni.
C programmers never die, they are just cast into void.
-
Sk8erPeter
nagyúr
Amikor a céges környezet, és/vagy konkrétan Eclipse-re épülő UI* miatt Eclipse-hez vagy kötve, akkor nem fogsz Ideát használni.
*: vágod, van ilyen lehetőség, hogy az Eclipse modularitását kihasználva, saját plugineket készítve lehet az Eclipse API-t kihasználva készíteni arra épülő alkalmazásokat. Maga az Eclipse, mint fejlesztőkörnyezet, nem meglepő módon ugyanerre épít.
Egyébként szerintem is fasza az Idea, de a munka nem mindig úgy van, hogy azt használsz, ami neked tetszik.
(#8007) M_AND_Ms:
És akkor, amikor rácsodálkoztál, azt reagálta, hogy ő mindig hibátlan kódot ír, és a kollégái is?
Amúgy ez elég durva, gondolom akkor ha mégis valahol hibát fedez fel, kiírogatással próbál szerencsétlenkedni, vagy fogalmam sincs, de azért ugye az ilyenek is az átlagnál magasabb fizetéssel elég jól elvannak, miközben finoman szólva nem emelik a szakma színvonalát...(#8011) ToMmY_hun:
Köszi, végre nem csak én képviselem ilyen határozottan ezt az álláspontot.[ Szerkesztve ]
Sk8erPeter
-
ToMmY_hun
senior tag
válasz Sk8erPeter #8014 üzenetére
Igen, ez totál egyértelmű dolog. Nem szimpatikus hogy a Java programozók ennyire el vannak kényelmesedve. Javaslom az áttekintést a C++ fórumba. Ott napokig megy a vita azon is, hogy egy pre vagy poszt inkrement jelent-e nagyobb overhead-et. Valahogy így kellene hozzáállni, hogy idővel valaki seniornak mondhassa magát.
[ Szerkesztve ]
C programmers never die, they are just cast into void.
-
Sk8erPeter
nagyúr
válasz ToMmY_hun #8015 üzenetére
Egyetértek, szerintem is. Mondjuk ezt már kezdőként is kéne erőltetni. Ráadásul itt sokszor nem is kis overheadről van szó, sokszor látok olyasmit is leírva, hogy mondjuk 4 ismétlődő metódushívás történik láncolva háromszor egymás alatt, különböző sorokban (ergo ez már 12-szeri beleugrás a metódusba), vagy hogy adott, hosszabbra sikerült metódus törzsén belül lazán le van írva vagy 10-szer, hogy getValami(), miközben az pontosan ugyanazt a referenciát/értéket adja vissza. Ilyenkor az a magyarázat szokott jönni, hogy há' de az nem számít, mit kell itt ilyeneken pörögni, meg takarékoskodni, kit érdekel, stb., pedig ezek az overheadek olyan szépen egymásra tudnak épülni, hogy rossz nézni a végeredményt (nem beszélve arról, amit említettem, hogy ez zsigeri szintű igénytelenséghez vezet hosszú távon). Magasszintű nyelveknél sajnos elég elterjedt szokás magasról lefosni a mikrooptimalizációt.
De van, aki nem hajlandó befogadni ezt.Sk8erPeter
-
ToMmY_hun
senior tag
válasz Sk8erPeter #8018 üzenetére
Pedig eléggé könnyen ki lehet deríteni mi a jó megoldás, leprofilozza az ember a kódot és voila'. Az optimális kódírásnál meg az arany középutat kell megtalálni a gyorsaság és olvashatóság között az aktuális nyelven, aktuális feladat függvényében. Nyilván egy real time képfeldolgozó rendszer esetén egy ilyen overhead is nagyon sokat számít, egy desktop Java app esetén, ahol mondjuk az első körös inicializálásnál fut le egy ilyen kód, ott magasról tenni lehet rá. Ahogy írtad ez inkább amiatt fontos, hogy ne szokjuk meg a lustaságot.
C programmers never die, they are just cast into void.
-
sutszi
veterán
válasz M_AND_Ms #8017 üzenetére
Tudnék mesélni... Amikor először szembesültem a problémával, nem akartam elhinni...
Mondja, Mr. Babbage, ha rossz adatokat ad meg a gépnek, akkor is jó válasz fog kijönni belőle?" Képtelen vagyok felfogni azt az értelmi zavart, ami valakit egy ilyen kérdés feltevésére késztethet. - by Charles Babbage
-
M_AND_Ms
addikt
Egy jó programozó egy négy megás memóriadumpot egy perc alatt átnéz és értelmez.
Vérbeli informatikus pedig, Win95-öt használ IE 4.0-val. Tűzfal, vírusirtó és ilyen úri huncutságokkal nem él. Ez mind csak a gyáva nyápicok szokása.Aki tejszínhabot szeretne, az inkább verje ki a fejéből!
-
veterán
válasz M_AND_Ms #8022 üzenetére
Ha TDD-ben fejlesztesz, tényleg nem sokat kell debugolni.
A másik témában én is Sk8erPeterrel értek egyet. Ennyire ne legyünk már lusták használni a ctrl + alt + f, vagy ctrl + alt + v - t.
[ Szerkesztve ]
https://play.google.com/store/apps/details?id=com.lovemap.lovemapandroid
-
MODERÁTOR
válasz Sk8erPeter #8014 üzenetére
Ezzel tisztában vagyok, jelenleg én is Eclipse-t használok. De számomra megszokhatatlan.
"Ott szimatol a sarkadban vasfogait csattogtatva, minden egyes hétköznapod: kirúzsozott medvecsapda."
-
floatr
veterán
válasz Aethelstone #8001 üzenetére
Rendben
A mi esetünk annyiban speciális, hogy a DBA megszabta h mivel exportálhatunk.
(#8006) mobal Ezeket a hipszter dolgokat sosem szerettem
[ Szerkesztve ]
-
pvt.peter
őstag
Sziasztok,
Akadt még egy kérdésem ami lehet, hogy hülyeség, de lehet hogy nem.
Ha van egy függvényünk, akkor az alábbiak közül melyik változatát érdemesebb használni?
Itt most a hangsúly azon van, hogy ős típusú vagy már kapásból leszármaztatott típusú legyen az a bizonyos változó.
Ez most nem összekeverendő a "dependency injection" -el.
A temp lokális változóhoz nem lesz később hozzárendelve semmilyen más érték.public void function1(){
List<Object> temp = new ArrayList<Object>();
}public void function1(){
ArrayList<Object> temp = new ArrayList<Object>();
}Ez egy .50-es rombolópuska, elég szép visszarúgással.
-
pvt.peter
őstag
válasz Aethelstone #8028 üzenetére
jogos észrevétel, elnézést a megfogalmazásért
és mi a magyarázat erre?
kevesebb overhead?
egyszerűbb, kevesebb bájtkód jön létre?
vagy esetleg jobban tud optimalizálni a VM?Ez egy .50-es rombolópuska, elég szép visszarúgással.
-
F1rstK1nq
aktív tag
válasz pvt.peter #8029 üzenetére
Így megmarad az az előnyöd, hogy csak a Lista implementációját változtatod meg példányosításkor, a kód többi része változatlan marad. (Például ha úgy döntesz, ArrayList helyett LinkedList-et használsz később)
Clean Code szerint egyébként érdemes szinte minden esetben a referencia értéknek a még legmagasabb értelmes interfészt megadni.
Adrenaline is natures way of telling you 'don't fuck up.'
-
Aethelstone
addikt
válasz pvt.peter #8029 üzenetére
Többalakúság.
Problémák:
Ha szeretnéd kicserélni mondjuk egy LinkedList-re az ArrayListet, akkor nem tudod megtenni, mivel az eredeti változód típusa explicit ArrayList. Ha biztosan tudod, hogy az a változó az idők végezetéig ArrayList marad (ezt nem tudhatod), akkor maradhatna.
Másrészt meg nem szép. Kódolási konvenció a Collectionok esetében, hogy nem implementációt, hanem interfészt adunk meg ilyen esetben.
Érdemes "megszeretni" az interface típusú deklarációt, mivel egy csomó framework is így műx, pl. a Spring-es dependency injection esetében is interészekeket injektálsz, nem implementációkat.
Teljesítménygondok nem hiszem, hogy lennének.
szerk: Kolléga megelőzött
[ Szerkesztve ]
MI 10T Pro 8/256 , Arsenal FC - Go Gunnarz...
-
Aethelstone
addikt
válasz Aethelstone #8031 üzenetére
Egyébként kicsit általánosabban, lehet az, hogy implementáció és nem interfész típusú a változód, de csak abban az esetben, ha valami olyan metódust, tulajdonságot akarsz használni, ami az interfész nem biztosít, de az implementáció igen.
MI 10T Pro 8/256 , Arsenal FC - Go Gunnarz...
-
F1rstK1nq
aktív tag
válasz Aethelstone #8032 üzenetére
Így van, én is erre szántam a "még legmagasabb értelmes interfészt megadni" részemet, de lehet a tiéd jobb megfogalmazás.
Adrenaline is natures way of telling you 'don't fuck up.'
-
pvt.peter
őstag
Értem. Köszönöm a válaszokat @F1rstK1nq és @Aethelstone.
Ez egy .50-es rombolópuska, elég szép visszarúgással.
-
nagyúr
Egyebkent ha valakit erdekel 100%-os tavmunka, az szoljon ram. Alapvetoen Javasokat keresunk, de kifejezetten onjaro tipusokat, minel szelesebb latomezovel.
while (!sleep) sheep++;
-
pecze
aktív tag
válasz Aethelstone #7999 üzenetére
köszi, most volt időm foglalkozni vele
-
ToMmY_hun
senior tag
Arra lenne tippje valakinek, hogy egy FX-es Maven projekt esetén miért fut le hibátlanul konzolból java -jar foo.jar megoldással, míg sima duplakatt módszerrel azt írja a JRE hogy nem található a main class? Megnéztem manifest-ben, benne van a main class elérhetősége, valamint ha nem lenne akkor konzolból se menne.
[ Szerkesztve ]
C programmers never die, they are just cast into void.
-
Orionk
senior tag
[HAXE][Java][ObjektumOrientáltság]
Sziasztok !Szinte biztos vagyok benne, hogy rossz helyre írok, de nem találtam olyan topicot, ami a HAXE programozási nyelvről szólna. Most kezd úgymond felfutni és egyre több cégnél kezdik használni.
Foglalkozik-e valaki közületek vele?
Tudnátok-e ajánlani olyan oktató oldalt, tutorialt, stb..., amit próbáltatok és jól végigfuttatja a tanulót az alapokon?Én kezdő java fejlesztő vagyok. Tehát ismerem az alapokat és az objektumorientáltság alap elméletét. Ezekhez mérten szeretném elkezdni a Java mellett a HAXE-ot is tanulni. Majd Java és HAXE együttesével szeretnék foglalkozni.
köszönöm
[ Szerkesztve ]
-
Sempronius89
tag
Sziasztok!
Teljesen kezdőként az alapoktól egyenlőre hobbiból szeretnék java, vagy C++ programozást tanulni.
Azt szeretném kérdezni, hogy milyen könyveket, neten elérhető anyagokat ajánlanátok az első lépések megtételéhez?
A választ előre is köszönöm!
BUÉK -
veterán
-
Atlantisz48
őstag
Üdv!
A segítségeteket szeretném kérni a NetBeans fejlesztő környezet kapcsán.
Én úgy szeretném ott futtatni a programjaimat, hogy fogom a Java fájlt amit előtte Notepad++ ba vagy jegyzettömbben írtam, és egyszerűen, csak ráhúzom a a NetBeans felületére, ez eddig menni is szokott, meg is nyitja szépen, de futtatni nem tudom. És nem tudok, rájönni, hogy miért.
Van esetleg ötletetek, hogy miért?Üdv:
Zoli
-
Sk8erPeter
nagyúr
válasz Atlantisz48 #8043 üzenetére
Mert projektet kell létrehozni, és annak részeként fordítani+futtatni (ez így szokott lenni az IDE-knél).
Sk8erPeter
-
Orionk
senior tag
válasz Oppenheimer #8042 üzenetére
Szia !
Ezek a kurzusok fizetősek?
Úgy látom, hogy csak akkor lehet elkezdeni őket, amikor indul a COURSERA következő tanfolyama ? -
veterán
-
Atlantisz48
őstag
válasz Sk8erPeter #8044 üzenetére
Rendben, köszönöm.
-
Orionk
senior tag
válasz Oppenheimer #8046 üzenetére
köszi
Én egy olyat keresnék, ahol saját magam bármikor végigmehetek az oktató kurzusokon, példákon keresztül.
Ha valaki ismer ilyet és jónak találja, akkor légyszíves oszd meg.köszi
-
Lacces
őstag
Helló!
Segítség / Vélemény kellene. Én új vagyok ebben a Java-ban, bár van C#/.NET tapasztalat, tudásom.
A koncepció: lenne 2 java-s projekt:
- A projekt
- B projekt, ami egy JavaFX-es projekt, és ennek kellene használnia az A projektben lévő osztályok metódusait. Egyfajta API hívások zajlanak.C#-ban ez nem nehéz, mert ott ugye van 2 solution és referencia alapján behúznám B-t tartalmazó solution-hez az A projektet.
No de Java-nál ez hogyan műkődne? (Én olvastam, hogy JAR import fájl, de ezt nem látom át.)
Én az A és B-nek is külön git report tartanék fel, mert A projekt a motor / engine, B projekt, az asztalis GUI alkalmazás ami hívogatja az A osztályok metódusait, illetve valószínűleg a jövőben lesz egy C projekt, ami ugyanugy az A-t használja fel, csak az nem asztali GUI, hanem egy webes alkalmazás lenne.
Plusz, akkor már lehetne kísérletezni a Continous Integration-nel is.Ha esetleg erről kaphatnék egy step-by-step tutorialt, vagy hogyan kell rákeresni a neten.
Azt tudom, hogy van Java-ban a maven vagy gradle (utóbbira szavazok).C#-nál egy saját nuget szervert hoztak létre a többiek, és oda voltak mindig feltöltve a legújabb verziók a projektekről, így a másik projektnél mindig a legfrissebb verzió jelent meg build során.
Itt is valami ilyesmit kellene összehozni a Java-ban? (valami belső package kezelőt?)Egy Java csapatba átdobott (egyetemen használta utoljára Java-t) fejlesztő kér segítséget
Van ilyen lehetőség is. De ez azért nem tetszik, mert a többi "kezdő" fejlesztő, más folder alatt dolgozhatnak (más útvonal)
[ Szerkesztve ]
Új hozzászólás Aktív témák
A topicot kiemeltem. Valaki nem akar egy nyitó hsz-t írni?:))
- Azonnali VGA-s kérdések órája
- Ez a mondat angolul?
- Windows 11
- OLED TV topic
- Folyószámla, bankszámla, bankváltás, külföldi kártyahasználat
- Háztartási gépek
- Olcsóbb lett a Tesla Full Self-Driving szoftvere
- Crypto Trade
- Androidos tablet topic
- Samsung Galaxy Watch4 és Watch4 Classic - próbawearzió
- További aktív témák...
- -50% Lenovo ThinkPad T14 Gen 3: i5 1250P (12mag/16szál!!!),16GB,512GB,TOUCH,Win 11Pro,gari 2025.9.2.
- Samsung Galaxy S24 Ultra 12/512gb, Titánszürke, 1 hetes, csak kipróbált, 3 év garanciával, eladó!
- HP ENVY x360 15-fh0755ng Convertible - ÚJ - 15,6" notebook - Ryzen 5, 16GB, 512SSD, Win11
- Iphone 12 64GB független 94% akku
- HP PROBOOK 450 G9 (6A150EA) - ÚJ - 15,6" FullHD IPS üzleti notebook - i3-1215U, W11pro