這麼說的人是沒啥程式設計思想的。一個語言自然有其特點的，高階程式語言除了易用，上手快，基礎庫強大等特點，還有就是使用的人群要多，社群活躍。Java開源易上手，健壯跨平臺等特點吸引了大量的開發者。而語言畢竟是個工具，以後可能還會出現比Java語言更強大的工具，就好比Java是在C、C++基礎上發展來的一樣。

但一些思想性的東西是會一直照亮人的思想的，設計模式就是此類，它是前人總結的程式設計思想的精華，是給你我指出設計程式碼結構的解決特定問題的模式。我個人認為這種思想性質的內容一百年都不會改變多少，Java能用這類模式寫程式碼，Python一樣也能用，語言只是工具，程式設計思想才是精髓。

作為一名專注於科技領域的程式設計師，我來回答一下你的這個問題。

設計模式提供了23個漂亮的盒子，幫你整理你的衣櫃，外加一系列擴充套件機制，好讓你自己定義新盒子。對我們這些衣櫃像狗窩一樣，幾乎沒有盒子、袋子、隔板或者抽屜的人來說，設計模式真是大救星。我們只要改建一下屋子，把衣櫃擴大4倍，眨眼之間它們就能變得和百貨商店的貨架一樣乾淨了。

。。。

變大是Java中無法迴避的東西。Java就像是俄羅斯方塊，不過積木和積木之間的空隙都填不滿，結果只能越堆越高。

雖然《設計模式》的寫作是對廣大程式設計師的一記響亮的耳光——假設這個世界上只有C++和Java程式設計師。

Java語言雖然使用率高，但是其本身是有一定的缺陷的，就是囉囉嗦嗦。

有時候真的覺得Java是一個囉囉嗦嗦的女朋友。一個簡單的功能，就比如hello world，她也要整出一大坨程式碼才能在控制檯中輸出這十個廣大程式設計師熟悉的字元。

然而，設計模式在程式設計思想層面提供了一定的程式設計方式，就比如六大基本原則，以及諸如工廠模式、觀察者模式、裝飾模式等等。

這些設計模式雖然並不能夠降低微觀的程式碼量，但可以減少大量相似功能編寫的重複，這就能夠實現DRY原則，畢竟，重複是導致bug的一大原因。

最後，沒有任何一種程式語言是完美無瑕的。

你可以說，php是世界上最好的程式語言。當然，如果你只會php，那麼我會很同情的看著你，就像都德的《最後一課》中那位老師告訴我們法語是世界上最美的語言。

語言接觸的多了，才能橫向比較各個語言的優點和缺點，在哪些應用場景適用，哪些有欠缺。你可以說指令碼語言的靈活以及在呼叫外部應用上的開發快速，也可以說靜態語言的穩重、安全。

設計模式也一樣，它不是設計來彌補某種語言的缺陷與不足，而是跳開特定的開發語言，在更高層次上去探討應用程式的構建，以使得年輕的程式設計師們有一條快速構建應用程式的參考路徑和設計範例。

當然，任何的模式都是可以打破，也是用來打破的。就像資料庫設計中的正規化，在特定場景需要透過反正規化進行設計和規劃。

加油吧，程式設計設計，在人工智慧的奇點到來之前，還有相當長的路要走。

看你從哪個層面來看待設計模式！

如果你從語言層面來看設計模式，那麼這個說法可以說是對的。有部分設計模式是彌補了Java語言上的不足，最明顯的就是單例模式。

在Java中本身沒有提供單例物件的建立，需要透過單例模式來實現，什麼餓漢式，懶漢式，多執行緒下還要關注DCL，volatile關鍵字等等，衍生了很多的面試題。

而在現代語言中，很多都提供了建立單例物件的語法，比如Scala,Kotlin的object關鍵字。

如果從程式碼設計層面來看，設計模式提供了一套可複用的程式碼結構，來解決特定問題。比如，當需要動態化某些可選部分時，可以使用策略模式。當需要一組操作來順序操作某個物件時，可以使用職責鏈模式。

從架構層面來看，設計模式對元件關係進行了解耦。

假設我們要實現一個檔案伺服器，有一個UploadService來進行上傳操作，可以呼叫ConvertService對檔案進行轉換。UploadService屬於核心模組「上傳模組」，而ConvertService屬於非核心模組「轉換模組」。

如果UploadService直接去呼叫ConvertService來執行轉換，那麼核心模組就依賴了非核心模組。如下圖：

非核心模組是相對不穩定的，核心模組是相對穩定的。核心模組依賴了非核心模組會導致核心模組也不穩定。所以可以使用策略模式來解耦：

看箭頭的方向，現在轉換模組依賴於上傳模組，轉換模組的變化不會影響上傳模組。依賴方向改變了，這就是傳說中的「依賴倒置」！

java的很多設計模式，尤其是行為模式，都是為了彌補語言本身沒有一等公民的函式而存在的。如果一個語言有一等公民的函式（比如JavaScript），可以砍掉大概一半的設計模式【策略模式】（Strategy Pattern）

其中的Context是一個所謂的“上下文”，不一定非得是個類，也可以只是一個函式/方法。最關鍵的是，我們其實根本不需要ConcreteStrategyX類，也不需要它們的物件。我們要的只是一個execute函式而已，我們甚至連execute這個函式名都不需要，只要能執行它就行。

看看函數語言程式設計是怎麼玩的（這裡以大家都熟悉的JavaScript為例）：

function context(func) {

// 做些什麼...

var result = func() // 有需要可以傳參

// 再做些什麼...

}

context(function() {

// 做些什麼...

return 123

// 是否需要返回值看需求

})

一個匿名函式引數func搞定。

Java能搞出這種類圖來，全都是因為Java沒有一等公民的函式，所以函式必須依附於類（靜態方法）或者物件（非靜態方法）。而玩靜態方法又沒法玩多型，而且類不能當成引數傳遞給其他函式/方法，所以只能用物件攜帶方法。而物件的方法必須有個名稱，為了統一，就叫execute。由於需要多型，所以我們必須提一個接口出來，在接口裡宣告execute的方法簽名。所有這一切說白了都是為了討好Java編譯器，否則它會給你顏色（red）看。

當然，自從Java有了函式式介面和lambda後一定程度上也能玩函數語言程式設計了。

【觀察者模式】（Observer Pattern）

這個在JS裡大家已經熟悉到不能再熟悉了：

}

又是一個匿名函式搞定！上圖裡的Subject#attach在這裡就是直接賦值。Subject#detach就是賦空值。Subject#notify就是呼叫一下匿名函式而已。而Observer#update就是匿名函式本身。

【訪問者模式】（Visitor Pattern）

能整成這樣我也是服了。說白了不就是訪問者需要判斷一下元素型別嘛。直接套用策略模式，在匿名函數里if-else一下不就行了？（當然還有其他方式，比如引入一個工廠。有模式匹配的函數語言程式設計語言如Haskell、Erlang、Elixir等玩起來更簡單）。

【裝飾器模式】（Decorator Pattern）

這才是函數語言程式設計的魅力所在！

function core1(arg1, arg2) {

// 做些啥

return 123

}

function core2(arg) {

// 做些啥

return 456

}

function decorate(core) {

// 做些準備工作

return function() {

// 做些啥，甚至可以改變引數

var ret = core(...arguments)

return ret

}

}

var decorated1 = decorate(core1)

var decorated2 = decorate(core2)

酷吧？又是匿名函式搞定！只不過這次的匿名函式是返回值。