• 招生咨詢熱線:4008-569-579 
  • 手機(jī)版
    用手機(jī)掃描二維碼直達(dá)商品手機(jī)版
招生咨詢熱線
4008-569-579
機(jī)構(gòu)主頁(yè) > 機(jī)構(gòu)新聞 > Java編程中哪些事情會(huì)困擾你?
機(jī)構(gòu)主頁(yè) > 機(jī)構(gòu)新聞>Java編程中哪些事情會(huì)困擾你?

Java編程中哪些事情會(huì)困擾你?

來(lái)源:北京達(dá)內(nèi)教育        時(shí)間:2023-05-25        熱度:40℃        返回列表

啊哈Reddit(某知名國(guó)外在線問(wèn)答社區(qū)),沒(méi)了你我們還能在哪里從魚(yú)目混珠的網(wǎng)絡(luò)中提煉真正的精華?就在這雜亂無(wú)章的論壇中,的的確確存在著這樣一些精辟的討論。

比如有個(gè)叫Shambloroni的兄弟發(fā)起了一個(gè)引起廣泛共鳴的話題(收到了150個(gè)回復(fù)和投票)。話題的開(kāi)始是他在吐槽 Java

有哪些方面最讓他感到厭煩,同時(shí)他又向其他程序猿征集關(guān)于編寫(xiě)Java時(shí) 令人蛋疼(傷感……)的故事。


下面我列出了一些最有意思的回復(fù)——你會(huì)同意嗎?

Try-catch 聲明之殤

雖然我才剛剛開(kāi)始編寫(xiě) Java 程序,但是在Java

中實(shí)現(xiàn)讓程序停頓一些時(shí)間然后繼續(xù)運(yùn)行這件事情已經(jīng)復(fù)雜的令我震驚。除了寫(xiě)下基本的指令完成停頓外,我還必須要用 try-catch

來(lái)包裹的這些操作。沒(méi)準(zhǔn)對(duì)于大牛來(lái)說(shuō)這不算什么,但是對(duì)我來(lái)講這太令人難過(guò)了。

還有跟所有 IO相關(guān)的異常也讓許多簡(jiǎn)單的事情變得繁瑣起來(lái)。比如我僅僅想簡(jiǎn)潔地做些事情,但最后總是會(huì)搞砸,。然后我不得不在所有方法上加上“throws

Exception”。

沒(méi)有,沒(méi)有,還是沒(méi)有

沒(méi)有無(wú)符號(hào)的整形。

沒(méi)有操作符重載。

沒(méi)有對(duì)象屬性。

沒(méi)有代理 (盡管我聽(tīng)說(shuō) Java 8 中可能引入了代理或類似機(jī)制,但我還沒(méi)細(xì)看)。

我同樣痛恨很多 Java 庫(kù)中引入模塊的方式(比如根據(jù)名稱加載模塊)。相對(duì)而言,我更希望在編譯時(shí)就能檢查我需要的依賴庫(kù)是否已經(jīng)加載了。

找不到愛(ài)…

我恨 Java,就是單純的恨。負(fù)責(zé)任地說(shuō),我從不使用 Java

寫(xiě)程序的最大因素就是因?yàn)槲液匏?。還有一點(diǎn)就是JRE糟糕的模塊化。就算你用了一些加載工具比如Launch4j,你仍然需要讓用戶安裝一個(gè)超過(guò)200 MB

的框架來(lái)運(yùn)行程序。

沒(méi)有g(shù)etter、setter

Java還缺少getter和setter注解。這樣可以更簡(jiǎn)單的添加和移除模板代碼。

缺乏亮點(diǎn)

Java 缺少一些殺手級(jí)的模塊。雖然聽(tīng)說(shuō)一些不錯(cuò)的模塊將被加入到Java 9.x 中,但目前為止這是我最大的槽點(diǎn)了。

非暴力不合作

我遇到的最大的麻煩就是如何一起使用基本元素和對(duì)象。例如, 把一個(gè)char[]

類型的變量轉(zhuǎn)換成一個(gè)列表別提有多費(fèi)勁了,而且我感覺(jué)這種操作根本沒(méi)必要這么麻煩。

心愿單

我最想要的就是像 Perl 中那種上下文相關(guān)的函數(shù)了,以及當(dāng)處理真正的異常時(shí),這些函數(shù)可以在一個(gè)語(yǔ)言中所扮演的角色。

我還希望 Java 可以支持智能打包返回值,這樣我們就可以像在Perl中那樣返回一個(gè)包含多個(gè)值的列表了。

我希望使用異常的標(biāo)準(zhǔn)庫(kù)還可以在不適合拋出異常的場(chǎng)景下使用并能夠處理失敗。

還有,另一個(gè)煩人的地方就是我在用 StringWriter 時(shí)候還要處理 IO 異常。

還缺些什么

缺少宏對(duì)我來(lái)說(shuō)使 Java 減分不少(我并不說(shuō)在 C/C++ 中使用的預(yù)處理器宏,而是在Lisp/Scheme 中使用的那種宏)。

不論做什么事情你都需要定義一個(gè)類,盡管你可能根本不需要一個(gè)類。比方說(shuō),我想把一段經(jīng)常使用的代碼提取出來(lái),然后在需要地方使用——為了達(dá)到這個(gè)目的,我必須要把這段代碼封裝成一個(gè)final

static的方法,并放在一個(gè)類中。這樣一來(lái)我還得費(fèi)勁去給類取一個(gè)方便理解的名字……本來(lái)這事兒可以很簡(jiǎn)單(這確實(shí)很簡(jiǎn)單, 尤其是當(dāng)你可以定義宏的時(shí)候)。

有沒(méi)有搞錯(cuò)

缺乏對(duì)泛型的支持。C++ 中的模板要強(qiáng)大的多。

事實(shí)上,在Java 中你根本不能在泛型中實(shí)例化一個(gè)類,除非你把這個(gè)類作為參數(shù)來(lái)聲明一個(gè)泛型。

你很難給一個(gè)類加上結(jié)構(gòu)函數(shù)并讓它銷毀這個(gè)類。RAII(一種資源管理模式,見(jiàn) C++)卻一直非常有用。

沒(méi)有操作符重載。C++ 允許你是將 == 操作符用于比較字符串。同樣的,大整數(shù)運(yùn)算因?yàn)橥瑯拥脑蜃兊暮茈y使用。

呃, 好吧

沒(méi)有無(wú)符號(hào)的基礎(chǔ)類型。這尼瑪是鬧哪樣啊!

還是getter、setter

1、null(最大槽點(diǎn))。

2、沒(méi)有g(shù)etter和setter注解(例如,沒(méi)有屬性)。

3、Java 只支持位置參數(shù)。我喜歡像Smalltalk 那種支持多樣化的參數(shù)形式,或者是強(qiáng)制使用關(guān)鍵字參數(shù)的Python 3。

比如在 Samlltalk 中調(diào)用一個(gè)具有兩個(gè)參數(shù)的函數(shù),可以這樣做:

myInstance myMethodWithFoo: arg1 Bar: arg2

在 Python中你可以使用下面的語(yǔ)法來(lái)調(diào)用函數(shù)并給函數(shù)參數(shù)賦值:

my_inst.my_method(foo=arg1, bar=arg2)

4、……不支持多分派(Multiple Dispatch)?

這些是我最先想到的,不過(guò)覺(jué)得應(yīng)該還有更多。認(rèn)真地說(shuō),使用回調(diào)函數(shù)一直是一個(gè)大問(wèn)題,因?yàn)樗闊┝?。不過(guò)Java 8 中解決了這個(gè)問(wèn)題,我還是很開(kāi)心的

=)

愚蠢的默認(rèn)值

默認(rèn)的可見(jiàn)性。如果沒(méi)有給變量或方法一個(gè)修飾符,那么這個(gè)方法應(yīng)該是私有的,而不是包內(nèi)可見(jiàn)。

默認(rèn)的修改能力。最終類型(在所有情況下)應(yīng)該是默認(rèn)的,并用“var”作為修飾符。目前的情況是,程序員很少會(huì)把一個(gè)方法的參數(shù)設(shè)置為最終類型,因?yàn)槟菢訒?huì)讓變量很快變得不可讀。同時(shí),在一個(gè)方法中重寫(xiě)參數(shù)也是很少見(jiàn)的情況。

集合接口。Java

中應(yīng)該提供一個(gè)可寫(xiě)的集合接口,現(xiàn)在集合繼承自這個(gè)可寫(xiě)的接口,只是把所有改變集合內(nèi)容的方法屏蔽掉。這樣就會(huì)減少現(xiàn)在你會(huì)在Collections.unmodifiable……()

和一些第三方的API中見(jiàn)到的那些令人困惑的歷史遺留方法。有了可寫(xiě)的集合接口,Java 將會(huì)變得更加類型安全。

缺少表達(dá)能力。在用過(guò)Scala (或是最新的PL)之后, 你會(huì)覺(jué)得Java 非常的繁瑣。這是最常見(jiàn)的關(guān)于Java 的吐槽,但它這就是事實(shí)。

說(shuō)說(shuō)異常

被強(qiáng)迫的處理異常——真主保佑你。誰(shuí)能告訴我為什么我非要用try-catch 來(lái)包裹每一個(gè)Thread.sleep()

……?我從來(lái)就沒(méi)有真正見(jiàn)過(guò)那個(gè)我被要求去處理的InterruptedException。

我知道我要說(shuō)的可能不是一個(gè)廣泛認(rèn)可的問(wèn)題,但是我真的同意checked

exception(應(yīng)被檢查的異常)很煩人。這些異常讓代碼變得面目全非還讓重構(gòu)變得不可能。我明白他們?yōu)槭裁创嬖?而且理論上也說(shuō)的通),但是他們沒(méi)為開(kāi)發(fā)者帶來(lái)什么實(shí)質(zhì)好處。不論你做什么,都不要留一個(gè)空的catch

塊,就算你認(rèn)為這個(gè)異常永遠(yuǎn)不會(huì)發(fā)生。你大可以把這個(gè)checked

exception用RuntionException(運(yùn)行時(shí)異常)重新封裝一下,再拋出去。

電話咨詢

電話咨詢

咨詢電話:
4008-569-579
回到頂部

回到頂部