Új hozzászólás Aktív témák
-
TBG
senior tag
Ebben az esetben én is inkább az enum-ot támogatnám. Nyilvánvalóan be lehet drótozni boolean segítségével 2 féle típust, de egyrészt nem bővíthető, másrészt meg egy másik fejlesztőnek nem beszédes. Max. ha hülyére van dokumentálva.
Másrészről ilyen esetekben a kedves kollégának is maximálisan igaza van, aki azt mondja, hogy nincs szükség ilyemi differenciálásra. Az egyes cikkek azonosítói(ár, szín, stb) bőven elegendőek és egyediek.
Elnézést a kedves kérdezőtől, de valószínűleg egy igen kezdő programozóról van szó, nem csak simán kezdő Java fejlesztőről.
-
TBG
senior tag
válasz
Peter Kiss #3472 üzenetére
Ezt meg én nem értem....
-
TBG
senior tag
-
TBG
senior tag
válasz
Scroll Lock #3432 üzenetére
Érdekes workaround.....
-
TBG
senior tag
Ah, hülye kérdésre hülye válasz...azt is kérdezhetted volna, hogy a pinára gondolsz? Nem? Miért nem?
Mivel a kérdésedben semmi olyan nincs, hogy az egyik miért lenne jobb, mint a másik, csak annyi, hogy miért nem, ezért sem értettem.
Azért nem gondoltam a STAX-ra, mert a SAX-ra gondoltam. Ez így megfelel?
-
TBG
senior tag
válasz
pakriksz #3402 üzenetére
(aminek a többségéről nem is tudok mindent),
Aham, tehát a Java a szar...
Egyre jobban értem azt akik ócsárolják a java-t tele van, lehetetlen dolgokkal, olyan triviális apróságokkal kell szenvedni vele hogy az hihetetlen.
Nem kötelező használni....tudod, Kun Béla egyszer azt mondta, hogy ha a kupleráj nem megy, akkor nem a bútorokat kell kicserélni, hanem a kurvákat....azok ócsárolják, akik Hozzád hasonlóan nem hajlandóak tanulni, fejlődni...új dolgokat megismerni.
Aki valóban meg akar oldani egy problémát, az nem a kifogásokat keresi, hanem a megoldást. A SAX parser kiváló megoldás lehetett volna, de dolgozni kell vele..igen. Az élet kemény.
-
TBG
senior tag
válasz
Peter Kiss #3373 üzenetére
Igaz. Egy cseppet benéztem. Az adapter arra megoldás, hogy ha van egy interfészed, aminek van 100+1 metódusa, de egy új metódust nem kell mindenhol feltétlenül megvalósítani, hanem alapértelmezésben csak egy üres metódusblokk lenne null visszatérési értékkel.
-
TBG
senior tag
válasz
Peter Kiss #3371 üzenetére
Interface esetén ezt nem lehet kivitelezni: ha bekerül az interface-be egy plusz elem, akkor azt a régi kódokban is implementálni kell
Elvileg egyébként erre is van megoldás.
-
TBG
senior tag
válasz
WonderCSabo #3365 üzenetére
ha valami nagy memória igényű cuccot töltök be
Ilyet én nem tennék singletonba..se lazy se eager módon...helper osztályok
Bár androidot még sosem programoztam, ezért csak eméletileg pofáztam bele
-
TBG
senior tag
válasz
pvt.peter #3358 üzenetére
Az interfész osztály és az absztrakt osztály közötti különbségek.
E kettő dolog között a különbség "szinte" csak az abstract és az interface kulcsszavak.
Mi még köztük a különbség? Melyiket érdemes használni?Azért ez nem így van. Az interfész gyakorlatilag csak meghatároz megvalósítandó metódusokat.
Ezzel szemben az absztrakt osztályban lehetnek absztrakt metódusok, amiket meg kell valósítani az örökösnek, DE lehetnek benne nem absztrakt metódusok is, amik valami konkrétumot csinálnak.Persze ezt lehet variálni, amikor egy absztrakt osztály megvalósít egy interfészt, de az implementációk absztraktok lesznek.....így azokat az örökösben kell implementálni...és ott már gyakorlatilag nem látszik, hogy az eredetileg az absztrakt osztály absztrakt metódusait valósítom meg vagy az absztrakt osztály által implementált interfész metódusait
És melyiket érdemes? Erre nincs egységes recept. Általánosságban elmondható, hogy ha többszörös öröklődést akarsz megvalósítani(ami Javában alapból nincs), akkor interfész, de ha tuti, hogy csak egy őst akarsz, de kellenek default metódusok is, akkor absztrakt. Perszem azt is lehet, hogy
Interface-->default class implements interface-->örökös
vagy
absztrakt class-->örökös
vagy
Interface->absztrakt class absztrakt metódusok-->örökös
szóval...a lehetőségek végtelen tárháza
-
TBG
senior tag
Nem elég részletes a workaround. Belenyúlt a gyári osztályba vagy csak egy @Override-t használt?
Szerk:
http://developer.classpath.org/doc/javax/swing/ProgressMonitorInputStream-source.html
Elvileg egy extend elég lenne, csak a ProgessMonitor ugyancsak int-et vár és nem long-ot.
76-93Szóval azt is extendálni kellene...
-
TBG
senior tag
+1
-
TBG
senior tag
válasz
Peter Kiss #3321 üzenetére
Igen. Max. a terminológia más
Amit én fejlesztek egy cégen belül alkalmazást, az nem API, a Spring az API és Framework.
-
TBG
senior tag
válasz
WonderCSabo #3319 üzenetére
Igazad van. Kompromisszum. Saját rendszerben több és kevesebb szabadsága van az embernek, mintha API-t fejleszt.
-
TBG
senior tag
válasz
WonderCSabo #3316 üzenetére
mert értelmesen hívogattam a metódust
Igen, Te értelmesen hívod, de láttam egy csomó API-t, ahol vannak ilyen aknák és egyesek bizony rá is lépnek.
-
TBG
senior tag
Az egész koncepció szerintem téves. Alapból a Car osztály Tyres collectionjához semmilyen módon nem kellene biztosítani hozzáférést. addTye(Tyre t), removeTyre(Tyre t), stb. metódusokon keresztül kellene csak engedni az elérést, különben az eredeti problémához hasonló eredmények születnek....én kapásból a setTyres(List<Tyre> tires) metódust nem is implementálnám...
-
TBG
senior tag
válasz
WonderCSabo #3306 üzenetére
!"úgy tűnik".equals("tudjuk")
-
TBG
senior tag
válasz
WonderCSabo #3304 üzenetére
Nem tudjuk, hogy mit akart.
-
TBG
senior tag
válasz
WonderCSabo #3302 üzenetére
Nem lett volna rossz az eredeti megoldás, ha a kerekeket nem ugyanabból a Car példányból veszi
-
TBG
senior tag
Az egészet nem értem egyébként.
Car car = new Car();
car.addTire(new Tyre(10));
car.addTire(new Tyre(11));Ez a 3 sor megcsinálja azt, amit itt szeretnél tenni...
List<Tyre> carTires = car.getTires();
System.out.println("Before: " + carTires.size());
car.setTires(carTires);Gondolom, azt vártad, hogy lesz egy 4 elemű listád [10,11,10,11] értékekkel? Vagy mi volt az elképzelés?
Egyébként így működött volna:public class Car {
private List<Tyre> tires = new ArrayList<Tyre>();
public void setTires(List<Tyre> t) {
this.tires.clear();
this.tires.addAll(t);
}
// Egyéb lekérdező metódusok
}
public class CarTest {
public static void main(String[] args) {
Car car = new Car();
car.addTire(new Tyre(10));
car.addTire(new Tyre(11));
List<Tyre> carTires = car.getTires();
System.out.println("Before: " + carTires.size());
Car anotherCar = new Car();
anotherCar.setTires(carTires);
System.out.println("After (1): " + car.getTires().size());
System.out.println("After (2): " + anotherCarTires.size());
} -
TBG
senior tag
Igazából én ebben nem tudok segíteni..már könyv. Amit én a webes fejlesztésről tudok ( és minden szerénytelenség nélkül nagyon sokat már ) azt kb. az elmúlt 6-8 évben folyamatosan szedtem össze.
Szóval, egyetértek az előttem szólóval...a főnökeid szerintem ezt nem gondolták végig. Mert mindent meg lehet tanulni, de nem mind1, hogy mennyi idő alatt.
-
TBG
senior tag
Meglepi nem volt. A kód volt egy kicsit egy laikus műkedvelő munkája...persze az vesse az első követ...mi sem voltunk annak idején jobbak. Bár annyit azért elmondanék a kollégának, hogy egy pár olyan megoldás van benne, ami elkerülhető lett volna, ha legalább 1 Java tutoriált elolvas kicsit figyelmesebben....
-
TBG
senior tag
És akkor még ott lesz az abstract class is, amit gyanútlan Java fejlesztők nem mindig tudnak megkülönböztetni az interfésztől
-
TBG
senior tag
válasz
Dave-11 #3239 üzenetére
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...
}
}
Új hozzászólás Aktív témák
Hirdetés
A topicot kiemeltem. Valaki nem akar egy nyitó hsz-t írni?:))
- Azonnali alaplapos kérdések órája
- Audi, Cupra, Seat, Skoda, Volkswagen topik
- Nem lett arányos a fogyókúra
- Formula-1
- Ingatlanos topic!
- exHWSW - Értünk mindenhez IS
- Interactive Brokers társalgó
- Milyen légkondit a lakásba?
- Motorola Edge 50 Neo - az egyensúly gyengesége
- Spórolós topik
- További aktív témák...
- Apple iPhone 12 Pro 128GB, Kártyafüggetlen, 1 Év Garanciával
- Cooler Master CK550 RGB mechanikus (barna switch/magyar kiosztás)
- Újszerű Meta Quest 3 (128gb), 1 év garanciával +kiegészítőkkel
- Asus Prime B560M-K + i5 11500 + be quiet! + 32 Gb Patriot Viper 3.200 Mhz Beszámitok!
- Eladó Konfig Ryzen 7 7700 32GB DDR5 1TB SSD RX6800XT 16GB!
- 124 - Lenovo Yoga Pro 7 (14IMH9) - Intel Core Ultra 9 185H, RTX 4060 (48 hónap garancia!) (ELKELT)
- ÁRGARANCIA!Épített KomPhone i7 14700KF 32/64GB RAM RTX 5070Ti 16GB GAMER PC termékbeszámítással
- BESZÁMÍTÁS! 4TB Toshiba P300 SATA HDD meghajtó garanciával hibátlan működéssel
- Samsung Galaxy S25 Ultra 1TB, Kártyafüggetlen, 1 Év Garanciával
- BESZÁMÍTÁS! Asus TUF B450M R5 5600X 32GB DDR4 512GB SSD RTX 3060 XC 12GB Rampage SHIVA Chieftec 600W
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: PC Trade Systems Kft.
Város: Szeged