Seriozní porovnání .NETu a Javy

borekz

  • ****
  • 492
    • Zobrazit profil
    • E-mail
Re:Seriozní porovnání .NETu a Javy
« Odpověď #15 kdy: 28. 01. 2018, 09:33:03 »
Zrovna dll beru jako výhodu, protože se to rychleji načte. Načtení pár desítek knihoven jar trvá jednotky sekund.


Honza

Re:Seriozní porovnání .NETu a Javy
« Odpověď #16 kdy: 28. 01. 2018, 10:14:54 »
- Program by se měl psát tak, aby se v něm nedělaly testy na null. Otazník jako syntaktický cukr je tedy zbytečný.

To ale prakticky nejde, uz jen treba Rest metoda, do ktere ti framework rozparsuje http parametry. Musis testovat na null. Stejne tak ORM mapovani, nebo Modelyy neceho, taktez by mely mit moznost mit null a ty to pak budes testovat. Jak by jsi napr. u tridy AutaXMLModel resil, ze proste Auto nemelo zadany treba VIN? Jak to chces udelat jinak nez pres null?

Takze rekneme, ze ti prijde do rest metody

Kód: [Vybrat]
JAVA

getDistance(Firma z) {
  int psc;
  if( z != null && z.getDodaciUdaje() && z.getDodaciUdaje().getAdresa() != null) {
    psc = z.getAdresa().getDodaciUdaje().getPSC();
  }
}

C#

zpracujZakazky(Firma z) {
  int psc = z?.Adresa?.DodaciUdaje?.PSC;
}


V Javě když děláš 3 vrstvou architekturu tak máš celý kód zaneřáděný přinejmenším null checky, gettery a settery.

Kód: [Vybrat]
Smalltalk:

Firma>>dodaciUdaje: anObject
dodaciUdaje := anObject asDodaciUdaje

DodaciUdaje>>adresa: anObject
adresa := anObject asAdresa

*UndefinedObject>>asDodaciUdaje
 ^ NullDodaciUdaje new

*UndefinedObject>>asAdresa
 ^ NullAdresa new


Kód: [Vybrat]
| firma psc |
firma := Firma new.
psc := firma dodaciUdaje adresa psc.

Nekontroluji null ani jednou. Obdobne pro firmu, kdyby byla null.

jpu

Re:Seriozní porovnání .NETu a Javy
« Odpověď #17 kdy: 28. 01. 2018, 10:27:44 »
Dělal jsem poslední 2 roky profesně v Javě a předtím na VŠ v :NETu. Teď uvažuju přejít na .NET a dělám takový zkušební projekt. Napíšu tady nějaká porovnání těchto 2 platforem a snad se do této diskuze někdo další přidá a napíše své postřehy.

1. C# a Java. C#má značně bohatší syntax, ale trošku za Javou pokulhává ve filozofii výstupních artefaktů. V Javě je to vždy JAR soubor a je jedno, jestli je to knihovna nebo spustitelný JAR. Z toho plyne snadnost získání knihovny do Java aplikace: prostě získám JAR. U .NETu je to složitější, protože musím zkompilovat DLL knihovnu.

2. Každý JAR soubor může oproti DLL knihovně obsahovat i zdrojové souboury. Zkrátka v něm může být zabalený celý projekt se vším všudy. Navíc, ikdyž zdrojové soubory neobsahuje, každé IDE mi bytecode umí převést do Tříd a já si tak můžu AdHoc v IDEčku proklikávat zdrojový kód libovolné třídy z načteného JARka. Navíc i zkompilovaný kód si v Javě drží původní adresářovou strukturu a názvy souborů.

3. Příje mi, že C# je místy překomplikovaný. Např. můžu do 1 souboru dát více než 1 třídu a název souboru s touto třídou ani nemusí korespodnovat. Příjde mi to trochu nešťastné, protože se musím manuálně starat o to, aby to bylo dodrženo. S tím souvisí i Namespacy, které vůbec nemusí dodržovat adresářovou strukturu v projektu. Systém balíčků v Javě a pravidlo, že jméno Package s tečkovou notací musí dodržovat umístění v adresáři a název souboru musí korespondovat s názvem třídy mi přijde lepší.

4. Zkoušel jsem i .NET Core a Java jednoznačně válí s Mavenem. .NET má několik jakýchsi konfiguračních souborů projektu, Javě stačí jen pom.xml a v něm nastavím nejen závislosti na další JARka, ale taky můžu řešit build management.

5. Je to zvláštní, ale v .NET znatelně déle trvá, než se spustí nějaký jednoduchý Unit Test. Než se ten projekt zkompiluje, tak to prostě zabere čas. Příjde mi, že v Javě se Unit test spustí prostě adhoc, na nic se nečeká. Je to důležité, protože když nějakou třidu upravuju, chci si neustále pouštět průběžně unit testy a chci, ať se pustí prostě ihned. Jestli ono to není tím, že v .NETu se musí sestavit EXE soubor i při editaci jediné třídy, zatímco v Javě se vždy uplatní inkrementální build.

6. Celková uzvřenost kódu v .NET platformě. Nejen, že .NET knihovna je closed source a vy si nemůžete projít zdrojový kód a prostě upravit standardní knihovnu zděděním nějaké třídy, ale vy si nemůžete ani takto procházet naimportované DLL knihovny, protože i v nich budou chybět těla metod. V Javě si můžu jakoukoliv třídu z jakéhokoliv zdroje rozkliknout a podívat se, jak je naimplementovaná. Dost mi to teď chybělo v .NETu u XMLSerialize, který jsem potřeboval upravit pro línou deserializaci XML souboru - no way.
Vsak sam si si odpovedal, v podstate. Ale porovnanie zo skolskych projektov je ale neodborne

Re:Seriozní porovnání .NETu a Javy
« Odpověď #18 kdy: 28. 01. 2018, 14:40:00 »
- Program by se měl psát tak, aby se v něm nedělaly testy na null. Otazník jako syntaktický cukr je tedy zbytečný.

To ale prakticky nejde, uz jen treba Rest metoda, do ktere ti framework rozparsuje http parametry. Musis testovat na null. Stejne tak ORM mapovani, nebo Modelyy neceho, taktez by mely mit moznost mit null a ty to pak budes testovat. Jak by jsi napr. u tridy AutaXMLModel resil, ze proste Auto nemelo zadany treba VIN? Jak to chces udelat jinak nez pres null?

Takze rekneme, ze ti prijde do rest metody

Kód: [Vybrat]
JAVA

getDistance(Firma z) {
  int psc;
  if( z != null && z.getDodaciUdaje() && z.getDodaciUdaje().getAdresa() != null) {
    psc = z.getAdresa().getDodaciUdaje().getPSC();
  }
}

C#

zpracujZakazky(Firma z) {
  int psc = z?.Adresa?.DodaciUdaje?.PSC;
}


V Javě když děláš 3 vrstvou architekturu tak máš celý kód zaneřáděný přinejmenším null checky, gettery a settery.

Kód: [Vybrat]
Smalltalk:

Firma>>dodaciUdaje: anObject
dodaciUdaje := anObject asDodaciUdaje

DodaciUdaje>>adresa: anObject
adresa := anObject asAdresa

*UndefinedObject>>asDodaciUdaje
 ^ NullDodaciUdaje new

*UndefinedObject>>asAdresa
 ^ NullAdresa new


Kód: [Vybrat]
| firma psc |
firma := Firma new.
psc := firma dodaciUdaje adresa psc.

Nekontroluji null ani jednou. Obdobne pro firmu, kdyby byla null.

Kde se dělá ve Smalltalku?!  8)

jpu

Re:Seriozní porovnání .NETu a Javy
« Odpověď #19 kdy: 28. 01. 2018, 15:08:22 »
Na roote 😀


Kit

Re:Seriozní porovnání .NETu a Javy
« Odpověď #20 kdy: 28. 01. 2018, 20:59:56 »
- Program by se měl psát tak, aby se v něm nedělaly testy na null. Otazník jako syntaktický cukr je tedy zbytečný.

V Javě když děláš 3 vrstvou architekturu tak máš celý kód zaneřáděný přinejmenším null checky, gettery a settery.

Zvláštní, null checky, gettery ani settery nemám v PHP ani v Javě. Kdo umí OOP, tak tohle smetí nepotřebuje.

anonym

Re:Seriozní porovnání .NETu a Javy
« Odpověď #21 kdy: 28. 01. 2018, 21:45:21 »
- Program by se měl psát tak, aby se v něm nedělaly testy na null. Otazník jako syntaktický cukr je tedy zbytečný.

V Javě když děláš 3 vrstvou architekturu tak máš celý kód zaneřáděný přinejmenším null checky, gettery a settery.

Zvláštní, null checky, gettery ani settery nemám v PHP ani v Javě. Kdo umí OOP, tak tohle smetí nepotřebuje.

Tak mi vysvětli, jak bys řešil tu věc s objektem, co ti přijde z RESTu. To by mě fakt zajímalo, jak se vyhneš zběsilým null checkům.

Kit

Re:Seriozní porovnání .NETu a Javy
« Odpověď #22 kdy: 28. 01. 2018, 21:53:49 »
Zvláštní, null checky, gettery ani settery nemám v PHP ani v Javě. Kdo umí OOP, tak tohle smetí nepotřebuje.

Tak mi vysvětli, jak bys řešil tu věc s objektem, co ti přijde z RESTu. To by mě fakt zajímalo, jak se vyhneš zběsilým null checkům.

Z RESTu mi do objektu přijde kolekce atributů. Pouze si zjistím, zda požadovaný atribut existuje a zda splňuje vstupní podmínky. Na null ho však testovat nepotřebuji, protože kdyby byl null, vůbec v té kolekci nebude.

Re:Seriozní porovnání .NETu a Javy
« Odpověď #23 kdy: 28. 01. 2018, 23:10:16 »
Jedna laická otázka.
Čo je také zlé na testovaní null hodnoty?

Kit

Re:Seriozní porovnání .NETu a Javy
« Odpověď #24 kdy: 28. 01. 2018, 23:34:10 »
Jedna laická otázka.
Čo je také zlé na testovaní null hodnoty?

Špatné ani ne, spíš je to zpravidla zbytečné a zdržuje to.

Afffsgg

Re:Seriozní porovnání .NETu a Javy
« Odpověď #25 kdy: 29. 01. 2018, 06:03:54 »
Niekto tu zaspal dobu, na null checky je jave map a flatMap skrz Optional

Kit

Re:Seriozní porovnání .NETu a Javy
« Odpověď #26 kdy: 29. 01. 2018, 06:13:50 »
K čemu testovat null, když máme výjimky.

soyo

Re:Seriozní porovnání .NETu a Javy
« Odpověď #27 kdy: 29. 01. 2018, 06:39:36 »
V jave ma zmysel vyhybat sa explicitnym null-kontrolam kvoli rychlosti. Vynimka hodena mimo metodu je radovo narocnejsia. Ak je to nutne, mame tu pattern monade. Otazka teraz je: o kolko je v c# syntax s '?' pomalsia pri ne-nullovych hodnotach?

jpu

Re:Seriozní porovnání .NETu a Javy
« Odpověď #28 kdy: 29. 01. 2018, 07:19:34 »
K čemu testovat null, když máme výjimky.
ty musis byt "vynimocny" programator. vyhodenie vynimky je ovela narocnejsie ako porovnanie na null.

Kit

Re:Seriozní porovnání .NETu a Javy
« Odpověď #29 kdy: 29. 01. 2018, 07:41:03 »
K čemu testovat null, když máme výjimky.
ty musis byt "vynimocny" programator. vyhodenie vynimky je ovela narocnejsie ako porovnanie na null.

Když je v aplikaci běhová chyba, vyhození výjimky je na místě. Obcházení výjimek je mnohem náročnější.