我感覺確實應用不理想，很多程式設計師，有些都是資深程式設計師了對於面向物件的概念僅僅停留在技術層面上。程式設計師還是沒有理解面向物件的基本概念，即使使用類似Java這種工具，也很難提高效率，更何況Java也被程式設計師帶得走形了。

軟體架構師必讀：面向物件程式設計思想（OOP）的由來與本質

軟體架構師必讀2：一文帶你理解面向物件(OOP)中類的本質

我總結了一下，當前理解上主要有這幾個原因：

對於面向物件在系統分析中的作用不掌握，還沒有掌握拆分物件、屬性和方法的基本原則，對於繼承的理解不足，對於過載、多型和介面存在濫用現象。專案籌劃倉促，沒有業務專家的加入或者業務變化比較大，拆分不好物件的設計不僅不能省力，還會給後期的更改造成麻煩。具體工具語言實現過程中，例如Java和Python，也沒有對面向物件提供明確使用規範。反倒是產生了“優先使用組合而不是繼承”這樣的經驗，這是技術上開倒車了。......

當然問題還有很多，但我看了許多面向物件的文章，發現困擾程式設計師，甚至是資深程式設計師的主要問題是對世界的認識不正確，就是問題1，不掌握的根源在於對世界缺乏認識論。這裡說的認識論包括分類、屬性、關係、方法、結構.....等要素之間的關係分析能力。

幾乎隨便找出一篇面向物件的文章，你都可以發現最主要的問題出在根源上：認識世界不正確。

我舉個例子大家就明白了：

我們公司說180天以前的發票不給報銷，這是自然語言，一句話就說清楚了。但是引入了一個詞叫“發票”，發票包含火車票、住宿票、計程車票、停車發票、飯費發票、旅遊發票，發票有個屬性叫做發生日期，

if 填單日期-發票.發生日期> 180 天 then 顯示("發票日期超過180天不予報銷")

......你看，要是沒有發票的這個指代作用，我們要費好多話。

一個好的面向物件的程式就是要做到概念（指代範圍）明確、邏輯清晰、語句精簡。這樣才好維護好更改。

兩篇別人面向物件的小例子，你有別的文章要分析也可以發給我，我感覺大部分問題都出現在例子上，就是對世界的認識方法上。

例子一：

前幾天看了一篇討論Java面向物件的文章，其中舉了一個例子：如何將水生動物、陸生動物、食草動物、食肉動物進行分類，如果把他們都做成動物類的繼承，你會發現有的食草水生動物不知道往哪兒放。最後決定動物是類，把食草、食肉，水生、陸生都做成介面，然後問題就成功得以解決。

如何對水生動物、陸生動物、食草動物、食肉動物進行分類，其實你仔細想一下，我們學過的動物學中有水生動物這個類別麼？並沒有！有什麼動物類別麼？你想起來初中生物學中哺乳動物的主要特徵麼：胎生、哺乳。沒有這兩個特徵就進入不了哺乳的類別。

那我們怎麼表示水生動物這個集合啊？彆著急，集合是一定要透過類別表示麼？類別也可以透過屬性表示。設定一個生活環境屬性：

水生動物={動物| 生活環境=水}

屬於物件和屬性的分析不合理。

例子二：

在另一篇文章中，設計了這樣一個繼承關係：也是推導了半天，最後得出結論面向物件不好使。

我們來看一下，父親和孩子是實體麼？這個是物件麼？，每個有孩子的人都是孩子，一個老人能管他叫孩子麼？那他曾經是孩子怎麼辦？他對於他父母來說始終是孩子吧？......邏輯暈得一塌糊塗。這麼分析是不會有結果的。

我們跳出來看一下，實體應該是人，例項是具體的人。父親和孩子是例項之間的一種關係。認識到這一層就知道要把父親和孩子分別做成人的方法：如果是get，返回引數就是找當前物件的父親和孩子。

小結一下：

如何認識世界、分析世界是一門學問，叫做本體論，是面向物件的哲學基礎。

學習語言和語文對程式設計至關重要，說到底程式語言還是語言，語言就有自己的規律和特點，抓住規律才能事半功倍。

程式設計師比社平工資高70%？程式設計的本質是什麼？能力強還是分配不公

低程式碼無程式碼平臺的未來在哪裡？程式語言的進化史告訴你答案

軟體架構師必讀：面向物件程式設計思想（OOP）的由來與本質

中國為什麼沒有自己的程式語言？哲學、數學和語言學基礎是關鍵

我覺得面向物件的程式設計方法相對面向過程是一大進步，極大地提高了程式設計效率。

目前流行的函數語言程式設計，也不排斥物件。我最近在自學kotlin，我覺得kotlin集多種程式語言的優點於一身，是最有前景的程式語言，在kotlin中一切都是物件。

使用起來不理想，應該是沒領悟到面向物件程式設計的理念。

常見的理論，三大基本特徵、六大設計原則、二十三種設計模式。

三大特徵是繼承、封裝、多型。

六大設計原則是單一職責、里氏替代、介面隔離、開閉原則、迪米特法則、依賴倒置。

二十三種設計模式，具體有哪些題主自行度娘，此處不一一列舉。建議掌握幾個常用的，如工廠模式，單例模式，介面卡模式、觀察者模式。

系統學習完上述幾點後，你一定會有豁然開朗的感覺。

大型的系統就知道用面向物件的好處了，大多數人編寫了兩個軟體，就以為自己很厲害了，就跟堆雪人和建大廈一樣，竟然提出了這樣的疑問

第一是程式的規模，你蓋國家大劇院，要實地勘測，畫設計圖，再協調各方合作，面向物件就實用；你在自己院子裡修一個狗窩，至於這麼麻煩嗎？最好指令碼語言，或者乾脆別寫語言。大型程式的數量遠少於小型程式，應用程式設計師可能一輩子都開發不了幾個，所以，面向物件就總覺得除了麻煩沒優勢。

第二是程式型別，面向物件給出了嚴密的程式結構，程式碼重用的基礎是系統最核心部分需求要穩定。現在網際網路時代，軟體在為市場服務，市場人員一拍腦袋，整個需求就改了，這是加班的根源。所以即便用面向物件，也停留在很基本的層面，開發速度第一，複製貼上絕對比繼承多型好使。

因為你面向的不是物件，那用起oo來當然有問題。就好比你生活在熱帶雨林，卻讓你去規劃沙漠綠化，肯定有問題。

首先‬面向物件‬是一種設計思想‬（OOD），如果你面臨的問題可以用物件、類的思路去模擬和解決，那你必定可以用OOL來實現它。如果本身模型就建不起來那就別提OOL了。

其次‬OOD是自頂向下‬的‬。一般來說一個工程專案可以不斷拆解，拆為多個子系統，大粒度的拆解往往是很適合用OOD的。因為那可以讓你很快捋清楚各個子模組的關係和它的屬性範疇。

但是拆到很細的粒度的時候，OOD可能會顯得設計臃腫（over-design）或者難以分類。這時候你面臨的可能是一個複雜行為的處理，那這時候就可以使用面向過程或者面向狀態的思想來處理更為妥當。

設計思想永遠都不是‬一塵不變的‬。能解決問題的就是好的。當然目前很多人對架構的理解是錯的。我們討論的並不是一個架構問題。我們討論的是“結構問題”（Construction）。即一個合適的設計思想組合，應該是清晰的、易管理的、最短路徑的。我們不應該刻意去追求一種純粹感。

所以語言的設計一直在向這方面演變。近些年流行的一些程式語言就支援上述特性。而JAVA相對來說比較古老，早期單純的面向物件帶來了一陣新鮮感，似乎萬物可以物件化的確很香。但是真正做工程的時候你會發現前期真的下沉地很快，但是後期就像水杯裡的微小顆粒它就是不容易沉澱下去。

最後一點，當下流行的語言一定是適合絕大多數專案‬的語言‬‬。一門語言好不好用最簡單就是看它到底流不流行。它跟其他商品一樣也是市場選擇的結果。如果你的專案跟市面上相比沒什麼特殊，但別人用得很得心應手你卻覺得不好用，那一定是你不習慣或者使用方法出現了問題。

前幾天在知乎裡回答了另一個類似的問題：Golang何時取代Java？

我的回答核心是：全面取代不可能，區域性使用會很火。

原因無他，都是面嚮物件語言，僅僅只是改良而已。

新時代的這麼多程式語言，Python，rust，R，G等等等等，拿過來，都在用Java成熟的東西往上套，雖然都沒有打“oo”標籤，可何處不是“oor”的影子？

高階程式語言，從C（也算吧）到Java，也就跨過了面向過程和麵向物件二個時代而已，沒有新的劃時代意義的“面向xx”語言出來之前（也許正在醞釀中），OO依然是當下乃至未來的主流。

Java做為OO的標杆，還會風騷一代或者二代人。

而OO的從業者中，菜雞太多，有幾個能把OO三個特性五大原則說清楚的？又有幾個能用好六大經典designer pattern的？

這個基礎沒有呀，UDSA就能有飯吃，想把OO用好，那是少數人的事了。

總結一句，不是OO不行，菜雞太多。

用過程化的方式去設計，再用面向物件的語言去實現必然會產生使用起來不理想的錯覺，說的通俗點就是生搬硬套了面向物件的程式設計方法。

面向物件最要緊的是設計，也就是找到物件並按照物件的實質特質為它加手添足，讓它的精神隱藏在它的大腦中，而不是提在手上絆在足上，如果沒有上升到這個層面而套用面向物件程式設計方法就會礙手礙腳而得不償失！

面相物件方法應用問題：業務分析面向物件和構造程式的面向物件不是直接應對關係。把這個搞混了，就沒得玩了。

但問題是，開始時，直接把業務分析產生的物件模型對應到程式構造物件模型是直接的思路。當程式規模達到一定程度後，如果沒有超出業務模型理解，很難想出合理的構造模型。而面嚮物件語言常常把程式構造的本質隱藏起來，這就造就了一系列系統複雜性。

設計模式一定程度上揭示了這個問題，但更多人把設計模式當成慣用法去用，結果造成了設計模式濫用。

比較而言，函式正規化，直接把構造模型的語言迴歸自動運算本來的描述方式。這樣，物件化業務分析的結果無法直接對應到code，重新突顯了從業務模型到構造模型的設計過程，從而降低了實現程式碼的複雜性，提高了程式的可維護性和效率。

但不要認為物件方法對組織程式碼就沒意義：如果能夠有意識嚴格區分業務物件模型和構造物件模型的話，面嚮物件語言還是簡化構造模型設計過程的利器，也是從構造模型向程式碼實現直接對映妙招。當然，部分業務模型與構造物件模型可以直接對應，但應把這種情況當成特例處理，沒有反覆的設計稽核，不應直接使用業務物件模型。但這對於coder，是很艱難的。

這類問題是很常見的。還以正方形問題舉例：在業務觀念上正方形就是長方形的特例。但對於求面積計算的計算行為就不具備這種關係。

構建模型目標對著計算中的實體關係，而不是圍繞著業務模型的實體關係。業務模型與計算模型用語相同，直接導致程式設計者先入為主。先入模型如此頑固，導致大量設計錯誤。這是面向物件方法論中的大問題。所謂敏捷中的小步重構和雙人程式設計甚至TDD幾乎都是解決這個問題。

這個問題本身就是坑。

就好像商場裡邊你正在看衣服營業員問你要買幾件啊？要買幾號的呀？

提問的時候本身已經做好了一定的假設，把對方裝在了坑裡。

事實是使用起來非常理想。不但降低了開發成本，提高了開發速度，而且提高了程式的健壯性。程式的執行速度也有了保障。