告別相殺！面向物件和函數語言程式設計共存
作為結構化程式設計的一種，函數語言程式設計正受到越來越多的重視。而作為常用的一種程式開發方法，面向物件程式設計為程式設計帶來了更強的靈活性和可維護性。那麼兩者相較而言，究竟有著什麼樣的區別？應用場景又有何不同？
告別相殺！面向物件和函數語言程式設計共存
簡單來說，函數語言程式設計（“FP”）和麵向物件程式設計（“OOP”）具有相似的表達能力和封裝能力，它們都可以將程式封裝成可以自由組合的較小部分。
但是這兩個“思想流派”之間的還是存在著很多區別。其中最大的差別在於對資料和資料操作之間關係的不同處理。
FP 和 OOP 的區別
面向物件程式設計的核心思想是將資料和對資料的操作進行緊密耦合：一個物件除了擁有自己的資料，還擁有對資料操作的實現。這些物件對外隱藏這些具體的資訊。它們通過介面，進行響應的方法或訊息來和其它物件互動。 因此，在面向物件程式設計中，抽象的核心是資料，這些資料通過介面等API對外展示。
在面向物件程式設計中，人們所作的主要工作就是建立新物件或者通過增加新方法來擴充套件現有物件。
函數語言程式設計的核心原則是資料只與功能進行鬆散的耦合。你可以對同一個資料結構定義不同的操作。在這裡，抽象的核心是函式，而不是資料結構。函式隱藏了它們的具體實現、程式語言的抽象以及函式之間進行組合或表達的方式，例如泛型函式或組合函式。
在函數語言程式設計裡，人們的主要工作就是編寫新函式。
在自然界中，如果熊和鱷魚之間爆發衝突，地形會決定雙方爭鬥的結果。
對於函數語言程式設計和麵向物件程式設計來講，它們在什麼情況下，其中的一個比另一個更合適呢？ 因為這是一個實用的部落格，所以，我將忽略所有理論上的考慮因素，例如機械地推理程式碼的能力和實施專案時的限制條件，比如資源不足，時間不足等。
在實際的環境中，你認為這兩者中的任何一個會是壓倒性的“贏家”嗎？這個可能得花些時間好好想想。在你思考的時候，我會先享受一杯濃咖啡...
告別相殺！面向物件和函數語言程式設計共存
何時使用 FP？何時使用 OOP？
當然，答案是，業務程式設計主要是由功能模型，而不是面向物件模型進行控制的。 這是一個讓你覺得驚訝的答案嗎？如果你的頭腦裡只考慮Java，C ++，C＃和Ruby，也許這個答案會令你覺得奇怪。
你知道，所有的面向物件通常都是對訪問各種支援 SQL 的資料庫的模擬。 SQL是一種非常實用的資料庫操作的指令碼語言。你可以對資料庫進行設定，使得對它所有表格的訪問都是通過PL/SQL的儲存過程完成的，但是因為這樣會產生嚴重的程式設計問題，所以，實際中很少這樣做。
關係型資料庫的主要好處是它可以滿足未來的需求。如果你需要新的報告，那隨時可以建立它們。許多不同的應用程式可以與同一個資料庫進行通訊。這些程式之間的資料一致性可以通過資料庫的約束條件來強制實現。
如果你仔細研究一下，就會發現資料庫本身其實就是一個大的資料結構，而應用程式則是對資料庫中的資料進行的操作。幾乎每個商務應用的核心都是一個大的功能性的資料庫，也就是一個數據結構和一系列對資料進行的操作。
OOP 使用場景
但是，我們在應用程式中包含物件只是為了符合潮流嗎？ 或者說，我們在編寫應用程式時做的事情和建立資料庫時做的事情有什麼本質上的不同嗎？
這個問題答案就在於面向物件和使用資料庫各自有什麼好處。
一個精心設計的面向物件的架構可以輕鬆改變物件的組合方式。 隱藏實現和解耦使您可以輕鬆地更改物件之間的關係。使用面向物件本身，並不會使新增新的操作變得更容易。如果在程式碼中發現雙重排程和訪問的問題，你就能夠真正地感受到這一點。
但是，假如有一個訂單處理系統，如果你的業務規則發生了變化，需要相應地修改訂單的處理流程，你就會發現面向物件的優勢。 那些不受這些變化影響的物件和受影響的物件是互相隔離的。
另一方面，精心設計的資料庫會使新增新查詢和操作變得很容易。如果你需要以新的方式檢視現有的資料或者如果您需要向資料新增新的更新型別，它都能夠很好地處理。 客戶端應用程式在邏輯上與提高效能的索引等問題互相隔離。
這樣做並不會使改變關係變得更容易。如果更改管理結構，使報表和管理器的關係從一對一變為多對多的矩陣管理結構，那麼這種更改將破壞許多應用程式。
因此，如果我們記錄了所有在商業軟體中需要實現的內容，我們需要把那些代表長期的、相對不變的關係的東西放在資料庫中儲存，把那些代表短期操作、隨著時間的推移而發展和變化的內容，在應用程式中實現。
應用程式的堆疊通常比資料庫的堆疊高四倍，這很正常。事情確實發生了變化，企業也應該不斷地學習、成長和發展。
FP 的應用場景
那麼，我們通常所說的函數語言程式設計，也就是用多正規化語言中的函式式編寫的程式碼怎麼做？我們可以簡單地將面向物件程式改寫為作用於相對靜態的資料結構上的操作集合嗎？
通常來說，這樣都是可以的。但同時必須優先考慮這種關係的相對壽命。那些本身不太可能改變，但是被經常改變的實體所操作的內容應該以一種函數語言程式設計來實現，而那些相對經常改變的東西可以用面向物件的風格來實現。
如果每個管理器都有一個或多個報表，並且每個報表都只有一個管理器，那麼將這種關係通過API進行隱藏就幾乎沒有什麼好處了，因為在API中，管理器物件以隱含的方式來委託操作。對於這種關係，最好的處理方式是先構造資料，然後對資料進行操作。
但是關於運輸成本的規則很可能會改變，所以，最好你把它封裝起來，以便程式的其它部分不被將來可能的變化所影響。
因為好的軟體需要滿足不止一種需求，所以，它們一般都包含這兩種風格。
41bcdf6703584fc58d197b1b04af4990.jpg
，裡面會分享一些高階面試題，還有資深架構師錄製的視訊錄影主要針對Java開發人員提升自己，突破瓶頸，相信你來學習，會有提升和收穫。在這個群裡會有你需要的內容 朋友們請抓緊時間加入進來吧