一、公司沿革

我想告訴您一個故事，展示OOP如何幫助應對大型系統的複雜性。這對於理解OOP的目的是必要的。

曾幾何時，有一家提供星際航運服務的小公司……

我們稱它為 Galaxy Rush。它僱用了5個人。一個在財務部門工作，第二個在倉庫工作，第三個負責送貨，第四個負責廣告，第五個管理整個企業。

他們工作非常努力，每件事都取得了成功。這家公司名聲很好，賺了很多錢。但是年復一年的訂單越來越多，老闆不得不額外招人。倉庫多幾個，送貨多幾個，財務多一個，廣告專家多一個，擴大公司的市場份額。

那就是問題開始的時候。人多了，他們開始互相擋路。

營銷人員在新的廣告活動上耗盡了銀行賬戶，因此沒有錢購買急需發貨的產品。

倉庫有 10 個全新的超級驅動器，每月一次運送給客戶。一名快遞員飛來為另一位客戶帶走了一個超級驅動器，導致 10 個超級驅動器的常規訂單延遲了一個月。第一個快遞員根本不知道另一個訂單是由第二個快遞員填寫的。

新任副理派快遞員坐飛船去採購更多貨物。與此同時，其他人都在等待可用的宇宙飛船出現。有大量緊急交貨，但這位助理只負責監督採購，並努力做好自己的工作。 員工履行職責越好，他就越會干擾他人的工作。

Java university

分析情況，老闆意識到飛船、現金和產品等重要資源沒有得到最佳利用。相反，他們受制於“你打瞌睡，你就輸了”的規則。任何員工都可以佔用其他人工作所需的資源，從而危及其他員工和整個公司。

必須做點什麼，所以老闆決定將這個龐大的公司分成幾個部門。他創建了運輸部、市場部、採購部、財務部和庫存部。任何人都不能簡單地乘坐飛船。航運部門的負責人收到了所有關於交貨的信息，並把船發給了利潤最高的訂單的快遞員。此外，倉庫不允許快遞員隨便拿走他們想要的任何貨物。相反，從倉庫中挑選產品變成了一個受控的過程。如果財務部門知道很快會有採購，就不會為營銷活動發放資金。每個部門都有一個公眾形象——部門主管。每個部門的內部結構都是它自己的業務。如果快遞員要取貨，她會去找倉庫管理員，而不是去倉庫。如果收到新訂單，則由運輸部門負責人 ( public-facing representative) 而不是快遞員 ( someone not authorized to interact with the other departments) 接收。

也就是說，老闆將資源和涉及資源的行動統一到組（部門）中，同時也禁止他人干涉部門的內部架構。 部門間的互動必須通過特定的人。

從OOP的角度來看，這無非是把程序分成對象。一個由方法和變量組成的整體程序變成了一個由對象組成的程序。對像有變量和方法。

問題在於任何員工都可以使用任何資源並向任何其他員工下達命令，而這一切都沒有監督或控制。我們施加了一個小的限制，但獲得了更多的秩序。而且我們也能夠更好地控制一切。

這是最純粹形式的分而治之。

2. 程序是如何創建的

我想談一談更重要的一點，它揭示了OOP的另一個優勢。您是否看到程序更像是動物而不是建築物？它們不是建造的。他們長大了。發展是不斷變化的。在施工中，您可以有一個好的計劃並精確地執行它。這不是軟件開發的情況。

很多時候在編程中，你不能按照你最初的意圖去做一些事情，必須進行大量的返工。客戶需求的變化更加頻繁。

但是，如果客戶提供了非常精確的規格怎麼辦？這讓事情變得更糟。看看隨著時間的推移，產品會發生什麼。

產品的成功將導致客戶想要發布一個新版本，然後一個又一個。當然，您需要做的就是對現有產品添加“小改動”。所以你可以看到產品開發是一系列不斷變化的過程。只是時間尺度不同。可以每週、每月或每六個月發布一次新版本。

我們可以從這一切中得出什麼結論呢？產品的內部結構需要以一種允許以最少的返工進行重大（和次要）更改的方式進行維護。

對象內聚

但這樣做比決定這樣做更困難。我們已經說過，程序由相互交互的對象組成。讓我們在板上繪製所有程序的對象，用點表示它們。讓我們從每個對象（點）到與之交互的所有其他對象（點）繪製箭頭。

現在我們將對象（點）組合成組。如果點之間的聯繫比與其他點的聯繫更緊密，則點應該被分組。如果一個點的大部分箭頭都指向其所在組中的其他點，則組的形成是正確的。我們說一個組內的點具有高內聚性，而不同組內的點具有較低的內聚性。

松耦合原則

有一個“松耦合原則”。一個程序被分成幾個部分，這些部分通常是分層的。這些層/部分的邏輯與其內部結構緊密耦合，而與其他層/部分的耦合非常鬆散。層與層之間的相互作用通常是非常規範的。一層可能引用第二層並且只使用其類的一小部分。這就是我們前面看到的“公司分部門”的原則，但是規模更大。

結果是我們可以根據需要重組一個部門以提高其效率，我們可以為該部門僱用更多的人，只要我們不改變與其他部門互動的協議，那麼所做的所有改變都會留在當地。沒有人需要重新學習任何東西。您不必重新設計整個系統。如果選擇好部門間交互機制，每個部門都可以進行這種內部優化。

選得好。但是，如果他們沒有選擇好怎麼辦？然後改變的能力很快就會耗盡，你將不得不重做整個系統。這必須時常進行。你無法預測未來，但你可以將重做的次數保持在最低限度。

抽象原則

選擇部門的結構以及它們如何交互是“抽象原則”。在編程中，它用於確定將程序分解為組成部分的最佳方式以及這些部分應該如何交互。我們可以重新應用該原則，將結果部分分成多個部分，直到我們將程序分解為單獨的類。

隱藏這些部分的內部結構並嚴格限制與其他部分的交互就是封裝。 封裝和抽像是OOP的基石。一個好的程序必須遵循這兩個原則。將來，我們將研究其餘原則並探索它們提供的好處。