面向對象程序設計,其本質是以建立模型體現出來的抽象思維過程和面向對象的方法。模型是用來反映現實世界中事物特徵的。
任何一個模型都不可能反映客觀事物的一切具體特徵,只能對事物特徵和變化規律的一種抽象,且在它所涉及的範圍內更普遍、更集中、更深刻地描述客體的特徵。通過建立模型而達到的抽象是人們對客體認識的深化。
面向對象程序設計方法是儘可能模擬人類的思維方式,使得軟體的開發方法與過程儘可能接近人類認識世界、解決現實問題的方法和過程,也即使得描述問題的問題空間與問題的解決方案空間在結構上儘可能一致,把客觀世界中的實體抽象為問題域中的對象。
面向對象編程一經問世,他就改變了開發人員看待代碼的方式,在 20 世紀 80 年代以前盛行的過程式編程,是非常面向機器的。開發人員需要對計算機如何工作有相當多的了解,才能寫出好代碼。
通過封裝數據和方法,面向對象編程使軟體開發更加以人為本。它符合人類的直覺,方法 drive()屬於數據組car,但不屬於組teddybear。
繼承出現的時候,那也是直觀的。汽車是car的一個子群,有著相同的屬性,這是完全合理的。
然後問題來了,假設你正在設置一個新程序,並且你正在考慮設計一個新的類。你回想起為另一個項目創建的一個簡潔的小類,你意識到它對你目前正在嘗試做的事情來說是非常完美的。
沒問題!你可以在新項目中重用舊項目中的類。
除了這個類實際上可能是另一個類的子類外,所以現在還需要包含父類。然後,你意識到父類也依賴於其他類,如此一來,最終會包含大量的代碼。
這幾乎說明了一切。重用類是很好的做法。事實上,它可以成為面向對象編程的一個主要優點。
但是,為了避免 DRY(don’t repeat yourself 不要重複自己),你最好編寫一個新的類,而不是包含大量的依賴項。
假如你已經成功地為新代碼重用了來自另一個項目的一個類。如果基類發生變化,會發生什麼情況?
它有可能會破壞你的整個代碼。甚至你可能連碰都沒有碰過。但是,有一天你的項目工作得很順利,但第二天就不這樣了,因為有人更改了基類中的一個小細節,而這個細節最終對你的項目非常重要。
使用繼承的次數越多,可能需要進行的維護就越多。因此,儘管重用代碼在短期內看起來非常有效,但從長遠來看,它可能會付出高昂的代價。
由於繼承沒有包含在面向對象編程的原始形式中,這個問題不能稱為面向對象的固有問題,這只是一個教條走得太遠的例子。
不僅僅是面向對象編程可能做過頭了。在函數式編程中,在屏幕上處理用戶輸入或列印消息是極其困難的。對於這些目的,面向對象或過程化編程要更好一些。
儘管如此,仍有一些開發人員試圖將這些東西作為純函數來實現,並將他們的代碼擴展到幾十行,以至於沒有人能夠理解。使用另一種範式,他們可以輕鬆地將代碼簡化為幾行可讀的代碼。
毫無疑問,函數式編程,而面向對象編程在過去幾年來受到了一些。
了解新的編程範式並在適當的時候使用它們是有意義的。如果說,面向對象編程是讓開發人員無論走到哪裡都能看到釘子和錘子,那這是不是將錘子扔出窗外的理由呢?不是的。你可以在工具箱中添加一把螺絲刀,或者一把小刀、一把剪刀,然後根據手頭的問題來選擇工具。
函數式和面向對象的程式設計師一樣,不要將你的範式當做宗教來對待。它們只是工具,都有自己的用途。你使用什麼工具應該只取決於你正在解決什麼問題。
現在,關於函數式編程與面向對象編程的爭論是相當之激烈,但是這些爭論可以總結為一個問題:' 面向對象編程的時代會不會走到盡頭? '
最有可能的情況是,面向對象編程將再持續十年左右。因此,在接下來的幾年,不要將面向對象編程從你的工具箱扔出去。但要確保它不是你唯一的工具。
文章參考: Towards Data Science 博客 原文作者:Rhea Moutafis
*版權聲明:圖文均來源於公開網絡資源,若有侵權,請聯繫我刪除!