1樓：馬遙
樓主所引用的話看似莫名其妙，其實把這段話和某人引用的《Art of Unix Programming》那段話連起來看，就能看出端倪。
其實確實都是經驗之談，殊途同歸，只是不太好理解罷了。
之前我給乙個新同事講如何設計良好的資料結構，來讓函式更簡單，思路更清晰。兩周後東西做完，慘不忍睹。
所以語言有些時候總是乏力的，上面這些總結並不能讓你明白你還沒領會到的東西，只是讓你在領會到這些東西之後，得到強化和共鳴。
2樓：
人認識世界的基本思維方式是先看這個世界有什麼東西，再看這些東西在做什麼，再看它們之間是什麼關係。有什麼就是物件和類，它們在做什麼就是函式、方法（其實我一直搞不清類的成員函式和方法這兩個概念的區別），組成這個世界的基本元素就是基本資料型別和CPU指令、基本程式設計語句。
OO的精髓在於它在首先看這個世界有什麼東西然後再看它們在幹什麼這一點上與人的思維非常吻合。
3樓：孫立偉
如果問物件導向的精髓，個人覺得就乙個詞，「物件」。其實就是你如何看待乙個軟體系統。至於把乙個軟體系統看成物件+訊息還是資料+過程更加科學，那是另乙個永恆的爭論。
根據我這十年來的開發經驗，基於/物件導向開發時，如何做好封裝才是基本。個人認為，就封裝而言，它和Data Structure Over Procedure的思路是一致的。也和題主所提到的那邊文章的中心思想是一致的，乙個更加合適的名字能夠促進你做更好的封裝。
所以，我的觀點是，物件導向，首先要做好封裝。這是基本中的基本，這也是我個人經歷中看到的出問題最多的地方。如何組織資料結構，如何對業務建立乙個好的資料模型，如何保證系統沒有冗餘，這是首先要做好的事情。
可事實情況是（至少我經歷過的），大部分系統連封裝都沒有做紮實，更不要去談多型和繼承了。
4樓：itlr
OO最開始的目的是「模擬」現實中的結構；其次是降低GUI程式設計的門檻，但這更多是乙個實現問題，而不是設計問題。
這是「短」而「淺」的資料（或者說從資料結構的角度說是「鬆散」的），怎麼模擬這種多形態的資料呢？
OO只是個名字，class和object也只是正好被這麼叫而已，C裡面有struct，這種設計或者需要已經是顯而易見的了，如果沒有struct，C就很難模擬和處理一大類問題（非經典資料結構）。OO也是這個道理，高階一點的語言沒有struct，用Class來代替了。
函式繫結在資料上是精髓也不是精髓，是精髓是因為事實上這確實是很明顯的特徵，但要深究的話C的struct內同樣可以包含函式指標，可以做同樣的事情，區別只在於OO比C的實現看上去直觀一點而已（是否必要是另乙個問題）；實際上很多高階語言的底層實現不就是C的這種結構嗎？如果你的高階語言設計裡面去掉了指標，你是不是必須要一種替代結構能繼續把行為和資料繫結到一起呢（或者說把函式本身當成資料使用）？Object就是了。
如果一定要說乙個OO做的事情，也絕對必要的話，就是「封裝」，「封裝」自然不是只有OO才有，而是一種general的思想，OO只不過是其中一種實現罷了。「繼承，多型」是實現使然，不是OO的必經之路，只不過大多數語言正好這麼做了而已。
5樓：
通過訊息通訊，解耦各個模組才是OO的精髓啊。
2023年3月4日16:45:40
更進一步地說，封裝、繼承和多型，都是當年simula時代的東西，當時只是有了物件的概念，而沒有現在OO的概念。
現在人們常常談論起的OOP是阿蘭凱在PARC的時候發明的。
因為他有生物學背景，所以想象中各個模組是各自以細胞的方式組織，好像放生物電一樣傳播資訊來相互通訊並組織程式結構的。
2023年3月4日18:59:31
更進一步地說，現代OO主導的軟體工程在建模的時候，需要對領域模型進行問題空間的建模。
所謂的資料並不是資料，而是問題中的實體。
所謂的操作並不是操作，而是乙個實體能夠接受訊息而採取的行為。
然後就是，根據契約程式設計，讓物件根據訊息而變化狀態。
電腦科學的一條至關重要的原則是控制複雜性。一定要解耦，一定要把模組很好地抽象出來。
6樓：伍寬
封裝不是物件導向獨有的。寫得好的c程式能明顯看到清晰的模組邊界和隱藏資料的做法。物件導向最大的特徵在於用抽象來簡化系統結構。但抽象的不好就是災難。
7樓：成增存
物件導向三大特性：封裝，繼承和多型；
用幾年下來，發現大家都在繼承，多型，然後是在此基礎上的各種模式，而「封裝」很少用到。
因為有了封裝，可以做面向介面設計和程式設計，讓協作更容易，讓開發更關注介面輸出，讓程式更加健壯和可控。
個人覺得：物件導向的最重要的特性，是「封裝」，或者是很多人稱為的「間接」。
LZ提到的「操作繫結在資料上」，任何乙個方法（函式）都是可以做到的，但說到物件，應該首先是物件職責的劃分，其次才是物件對外的服務介面和內部資料。
純粹個人多年程式設計下來的理解。
如何理解物件導向
玩玻璃珠 物件導向 物件導向程式設計，和面向過程程式設計都是程式設計正規化。也就是說是指導程式設計和抽象的思想。面向過程的設計思路是按照問題的解決過程來的。解決方法是通過函式來表示。著眼於解決步驟。解決這個問題我需要做哪些步驟？物件導向的設計思路是抽象並劃分參與者。也就是說，這件事是 誰 來做？再考...
如何用Haskell實現物件導向程式設計？
圓角騎士魔理沙 剛剛讀完了Haskell s overlooked object system，給出了幾個proposal，最後深入研究用HList encode recursive record。很有意思，比如說，class，label是first class的，所以多重繼承玩得很溜，比如說可以自...
物件導向程式設計的本意是什麼？
藍彼得 物件導向是抽象問題 分解問題 組織程式的一種方式。面向過程把問題抽象分解為乙個乙個的函式或者過程，然後通過呼叫這些函式來改變程式的狀態。物件導向把問題抽象分解為乙個乙個物件，然後物件之間發生關係 方法呼叫 改變物件的狀態，從而改變整個程式的狀態。本質上沒啥大的區別，物件導向又封裝了乙個層次而...