編程中為什麽要解耦？

本文轉載。我覺得很精辟。希望對正在學習面向對象設計的妳有所幫助。壹般來說。有這麽多的設計模式，我們應該使用面向對象的方法。都是關於脫鉤的。力的是降低各個模塊的依賴性，提高重用性。& gt& gt& gt& gt& gt& gt& gt& gt& gt& gt& gt& gt& gt& gt& gt& gt& gt& gt& gt& gt& gt& gt& gt& gt& gt& gt& gt& gt& gt& gt& gt& gt& gt& gt& gt在編程的過程中，最頭疼的不是邏輯的編寫過程，更不是算法的設計。最頭疼的是如何設計出壹個易於維護，擴展性好的東西。耦合問題是最煩的，因為很多人找不到，所以往往無從下手。自己真的很難知道，呵呵。以下是我的經歷。我通過例子說明耦合問題的影響。第壹個例子:開發壹個遊戲的時候，有很多實體類，通常屬於同壹條生產線，比如地形:土地、石頭、草原、雪地、沼澤等。，以及具有相同特性但功能不同的對象。新手壹般都是在程序的某個地方默默的創建這些應用對象，嗯，壹個，兩個，三個，慢慢的妳會發現程序不斷的出現。對象提供了五個接口函數，即讀寫操作，在程序中出現了幾十次。這個時候我就不要這個對象了，換成別的。要不要換幾十個地方？這就是問題所在。沒有抽象層次，必然導致維護困難。當對象數量膨脹到100時，就是壹場維護噩夢。當然，單壹的抽象層次解決不了新實體對象的事實。這是壹個令人頭疼的問題。管理對象的生產是壹個非常重要的模塊。對於壹些高級語言，比如C++，這裏唯壹能得到較好緩解的就是工廠模式下的工廠。我更喜歡用這種模式來管理對象。不學簡單的工廠是沒有實際意義的，但是我可以明確的告訴妳，第壹個帶妳進門開眼的模式絕對是工廠法模式。如果妳真的想學習模式，請先學習工廠方法。其使用的意義在於將對象的生成延遲到子類，而是使用接口來管理對象的初始化，將變化點從調用端分離出來。這裏我只能告訴妳為什麽要用設計模式，什麽時候要用。理解與否，取決於妳自己的實踐經驗和理解。我的悟性不高。當時我在學習設計模式的時候，看了很多遍還是不明白工廠模式的奧妙。在代碼量和項目經驗持續增加之前，很難用語言來表達它。但以上例子足以證明其意義，根本原因是脫鉤。第二個例子:因為我壹直在開發遊戲，所以引用的例子都不可避免的和遊戲有關。在這個例子中，如果妳寫了壹個完整的遊戲，妳壹定對它有所了解。遊戲總是有界面的，典型的界面就是菜單界面。菜單裏有按鈕吧？嗯，我設計的時候就想過這個問題。菜單和按鈕類別是分開的還是合並的？想了想，因為當時設計理念沒有到家，最後還是結合了。這肯定不好。為什麽？先不從概念上解釋。通俗的說法就是菜單和按鈕的對應關系是壹對多吧？沒有固定的關系，可能是1到2，1到3，1到10等等。，所以把它們寫在壹起是很死板的。僅基於這個證明，我們就可以發現，它們不得不被分離，它們最終的表現就是將它們組合起來，通過組合將按鈕的抽象層次註入到菜單中。結論:我覺得這是整篇文章最重要的部分，比任何所謂的等級理論都重要，因為它更通俗，更實用。很多人沒有學好面向對象，卻總覺得自己很窮。我也經歷過。學過面向對象、封裝、多態、繼承的人都知道它，並且認為他們理解它。其實很多精彩的因素讓妳誤會了，大部分。只要妳記住下面的原則，妳就壹定能利用好封裝。成員應該盡量使用protected和private，而不是public。盡量不要給成員屬性getter提供外部接口，也就是說不要公開成員。為什麽？這很簡單。暴露成員屬性必然會導致自身業務的泄露，從而導致類之間不必要的耦合。比如A類有成員A，程序需要改變A的數據，妳給B類提供壹個getter接口來訪問成員A，B類自己修改A好像沒什麽。其實就是類耦合。A的修改是A類的工作，是提供getter的習慣造成的。寫B類的時候把修改業務加錯了，降低了A類的凝聚力，程序逐漸越來越大，勢必越來越明顯。真的很難看出小程序的問題。就寫這麽多，拙見，希望對妳有幫助。