假設我們有一個具有不同元素的繪圖程序，例如圓形，矩形，三角形等等。不同類型的對象都需要類似的功能，例如draw()來顯示自己。非OOP編程中的多態性的替代方案？
我想知道程序員如何處理現在通常由多態性解決的問題，即通過不同元素的集合並調用不同對象的通用功能。
想到的一種方法是使用一個函數指針指向相應函數（或函數指針數組中的索引）的結構以及指向實際實例的void指針，並傳遞該指針到函數中正確的類型。但那只是我 - 一個對這個問題毫不知情的人會這樣做的。
我的確意識到這可能是一個不好的問題，但由於我在「古代」時代還沒有出現過，我真的不知道這個問題是如何解決的。程序編程中使用了什麼樣的方法，並且它具有性能優勢，因爲我們都知道，由於虛擬方法查找，多態性即使在像C++這樣的快速語言中也有開銷。
在程序語言，如C，這將通過定義每個自定義數據類型（大概表示爲結構）的draw()功能的單獨實施加以解決。任何常見的功能都會被分解成一個單獨的函數，該函數在每個結構的共享元素上進行操作（例如對象中心的x座標和y座標，它們將出現在每個結構中）。從代碼和功能的角度來看，這與使用多態的OOP佈局沒有多大區別，您仍然必須在基類中實現共享的draw()方法，並在特定的子類中重寫它。在程序語言的情況下，我們不會將這些函數定義分解成單獨的「對象」。
有一些奇特的方法可以從程序語言中獲得類似對象的行爲，例如聯合類型或帶有額外布爾值的單一整體類型，以確定是否正在使用特定元素。這將允許您編寫一個單一的draw()函數，該函數可以根據啓用了哪些元素來執行邏輯切換。在實踐中，我唯一見過的地方是基於CORBA的系統，其中用C語言編寫的程序必須模仿通過IDL傳播的OOP語言的一些行爲（即將Java對象翻譯成構造可以解碼爲C風格的結構）。
至於諸如C++和Java之類的語言中虛擬方法查找的開銷，這在面向對象的語言中是無法完全避免的。通過正確使用final關鍵字（它允許編譯器/ JVM優化方法查找表）可以很好地緩解這個問題。
這不是直接回答你的例子，但一個地址給你的評論，這顯示了一個錯誤的觀點恕我直言
我只是想知道有關具體問題，如果有最感興趣 更高效辦法避免的虛方法
也有一些是瞭解這裏的性能開銷 。 一切有一個折衷。設計模式和OO具有我們所喜愛的所有已知優點，但也具有缺點，例如太多類，內存開銷，由於許多方法調用等導致的性能開銷。
在另一方面舊的「程序」的方式有一些優勢也成爲目標;編碼是「簡單的」（不需要考慮如何設計系統，只需將所有內容都放在主體中），並且在很多方面開銷較少（因爲需要更少的類和更緊湊的對象，所以內存開銷更少） - 不需要虛擬表等等 - 而且更少的方法調用，所以也許更好的性能，動態綁定沒有性能開銷 - 不管現在的開銷如何 - ）。
但它不是什麼特定問題實例的權衡取捨，它是什麼經驗表明什麼是構建軟件的正確方法。 重用的代碼，模塊化和在獨立的測試（質量保證），可讀，維護協助，柔性的，以延伸是已被很好地理解的屬性應該是這樣的主驅動器在軟件開發中。
所以在某些情況下，C/C++中的程序員可以像你說的那樣做「老路」，但是對於這個特殊的程序來說性能上的好處值得這樣一個事實：沒有人之後能夠維持或維持？
再舉一個類似的例子：你可以問以同樣的方式？
爲什麼在web開發中使用多層體系結構？只要把一切都變成一臺服務器，這將是快了很多，因爲不會有任何的延遲在查詢後端和用戶界面的數據或遠程數據庫的查詢等
網絡延遲所有層 當然，你有一個觀點。但是，然後問你的自我，這可以作爲負荷增加？答案是不。因此，擴展性對您而言很重要，或者您希望保持「將所有內容放在一臺服務器上」的想法？如果你的收入來自電子商務網站，但事實上，你不能爲更多的客戶不會讓你的客戶感到高興，因爲你擔任第100真快......反正這是我的意見
所以你的問題是什麼像以前的面嚮對象語言一樣編程？我想象如何構造它們的程序，最終演變成面向對象的概念？例如。一個類通常與捆綁方法的結構相同。 – Cratylus
@Cratylus - 不，我的問題是不打算是廣泛的，我不知道類窗簾後面是什麼，我只是想知道關於特定問題，最感興趣，如果有避免的性能開銷更有效的方法虛擬方法。 – dtech
也許這會有所幫助： [http://stackoverflow.com/questions/524033/how-can-i-simulate-oo-style-polymorphism-in-c][1] [1]：HTTP： //stackoverflow.com/questions/524033/how-can-i-simulate-oo-style-polymorphism-in-c – John