在程式設計過程中，最頭痛的不是邏輯的編寫過程，更不是演算法的設計，最頭痛的是如何設計出一個容易維護，擴充套件性好的東西。而耦合問題是最令人煩躁的，它的存在很多人發現不了，所以往往無從入手，真是有苦自己知了，呵呵。以下是我的經驗之談。我通過例子來體現耦合問題的影響。第一個例子： 在開發遊戲的時候，有很多實體類，通常屬於一條相同的生產線，如地形：土地，石塊，草地，雪地，沼澤，等，具有相同特徵而功能不同的物件，新手們，一般是在程式的某個地方，默默地new出這些應用到的物件，恩，一個，兩個，三個，慢慢你會發現程式中不斷出現新物件，如果存在10物件實體，而物件的提供了5個介面函式，也就是，讀寫操作，在程式中出現了幾十次，這時，我不要這個物件了，換成其他了，那你是不是要改幾十處地方？恩，問題就是這裡了，沒有一個抽象層面，必然會導致維護困難，當物件擴大化到100個，這是一個維護噩夢，當然，單單一個抽象層面是無法解決new實體物件的事實的，這個是令人頭痛的問題，管理物件的生產是一個很重要的模組，這裡對於某些高階語言，如C++，唯一比較好緩解的是工廠模式中的工廠方法，我比較喜歡用這個模式去管理物件，簡單工廠就不要學了，沒什麼實際意義，而我可以很明確告訴你，第一個帶你入門，第一個讓你開啟眼界的模式絕對是工廠方法模式，如果真想學學模式，請先研究工廠方法，其使用的意義在於把物件的生成延遲到子類，而統一使用介面去管理物件的初始化，把變化點分離出呼叫端，這裡我只能告訴你為什麼要用設計模式，什麼情況下要用，理不理解就靠你自己的實際經驗和悟性了，本人悟性不高，當時在學習設計模式的時候，看了很多次依然沒有領悟到工廠模式的奧妙，直至程式碼量和專案經驗不斷地增加才頓悟出過中道理，確實是很難用文字來表達，不過以上的例子足夠證明它的意義，根源都是為了解耦。第二個例子： 由於我一直都在開發遊戲，所以所舉得例子不免都和遊戲有關，這個例子，如果你寫過一個完整的遊戲，必然有所瞭解，遊戲總會有介面，而其中比較典型的介面是，選單介面，選單裡有按鈕，對吧？恩，這個問題，我當時設計就考慮，選單類和按鈕類究竟是分開還是合在一起？想來想去，由於當時設計觀念沒到家，最後把它們合在一起了，這種做法絕對是不好的，為什麼呢？我們不要從概念上入手解釋，通俗的講法就是，選單和按鈕的對應關係是一對多，對吧？沒有一種固定的關係，有可能1對2，1對3，1對10等等，所以把它們寫在一起，是很僵化的，就單憑這種證明就可以發現，它們要分開，而它們最後的表現是合在一起，通過組合的方式，把按鈕的抽象層面注入到選單裡面，就可以動態地生成完整的選單，所謂的組合方式，不就是，選單裡面有一個存放按鈕引用的集合，希望你明白我所說的，具體我就不解釋了。 結語：我認為這裡是全篇文章最重要的，比任何所謂的分層理論都重要，因為它更通俗，更實際，很多人，並不是面向物件學得不好，但總覺得差什麼，我也經歷過，面向物件，封裝，多型，繼承，學過的人都知道，都認為自己瞭解了，其實不然，很多很奇妙的因素，讓你誤解了，大部分的人認為封裝很簡單，其實大錯特錯了，封裝是最奇妙的，也是最難用好的。只要你記住以下原則，必然能很好地用好封裝，成員儘量使用protected和private，不要去使用public.儘量不要提供給外部對成員屬性getter的介面，意思就是不要暴露成員，為什麼要這樣呢？很簡單，暴露成員屬性必然會導致自身業務的外洩，業務外洩，會導致，類之間的無謂耦合，如A類有成員a,而程式需要對a資料改變，而你提供一個B類可以訪問a成員的getter介面，B類在其自身對a修改，看上去沒什麼，實際上，就是類耦合，對a的修改是類A的職務，由於習慣的提供getter，導致了，在寫類B的時候錯誤地添加了修改業務，使類A內聚能力降低，程式逐步龐大必然會越發明顯，真所謂牽一髮動全身，小程式確實是很難看出問題所在。就寫那麼多，本人愚見，希望對你有幫助。