“你好，阿米戈！我想告訴你 OOP 的另一個好處。你看，程序更像是動物而不是建築。它們不是建造的，而是成長的。發展意味著不斷的變化。在建設中，你可以有一個好的計劃並嚴格執行。但在軟件開發中，情況並非如此。”
很多時候，您無法按照預期的方式做某事，您必須對程序進行大量返工。更常見的是，客戶的要求會發生變化。
“但如果客戶提供了非常詳細的規格呢？”
“看看隨著時間的推移會發生什麼。如果產品成功，客戶將希望發布一個新版本，然後是另一個版本，然後是另一個版本。而且，當然，你必須做出一些 «小的改變»現有產品。所以軟件開發是一連串的變化。只是節奏不同。新版本可能每週、每月一次或每六個月發布一次。”
“那麼我們從這一切中得出什麼結論呢？”
“產品的內部結構必須以一種允許以最少的返工進行重大（和次要）更改的方式進行維護。”
“你是怎樣做的？”
“我們已經討論過程序如何由相互交互的對象組成。讓我們使用粗點來表示板上所有程序的對象。我們將從每個對象（點）到所有對象繪製箭頭它與之相互作用的（點）。”
現在讓我們將對象（點）組合成組。如果點之間的聯繫比其他點多得多，則這些點屬於同一組。如果點的大部分箭頭指向其組中的點，那麼我們就正確地對對象進行了分組。同一組內的點稱為緊密耦合，而不同組中的點稱為鬆散耦合。
這被稱為“鬆散耦合原則”。一個程序被分成幾個部分，通常是層，其邏輯與其內部結構緊密相關，而與其他層/部分弱相關。層之間的交互通常是高度劃分的。一層可以僅使用其類的一小部分來調用另一層。
“同樣的‘分工’原則，但規模更大？”
“準確地說。這使我們能夠重組一個部門，使其更有效率，並僱用更多的人，如果我們不改變部門間的協議，那麼我們所有的改變都將是本地的。沒有人需要接受再培訓。我們不”整個系統不用返工，部門交互機制選擇好，每個部門都可以通過這種方式優化內部事務。”
“如果他們選得好。如果他們選得不好怎麼辦？”
'然後你很快就會用盡 «迴旋餘地» 來進行更改，並且必須重新設計整個系統。這種情況時有發生。我們無法預測未來，但我們可以最大限度地減少必須重寫程序的次數。”
“好吧。我看到了這樣劃分程序的好處，但是 OOP 是如何進入畫面的呢？”
“當我們選擇如何構建部門以及它們將如何交互時，我們應用'抽象原則'。在編程中，抽像用於確定拆分程序的最佳方式以及各部分應該如何交互。這個原則可以也重複應用於組成部分，直到我們將程序分解為單獨的類。”
“並且隱藏這些部分的內部結構，並嚴格限制它們與其他部分的交互方式——這就是封裝，對吧？”
“沒錯，封裝和抽像是OOP的基石，一個好的程序一定要堅持這兩個原則，以後我們再看看其他的原則，就會明白它們的優點。”
“好東西。我等不及了！”
GO TO FULL VERSION