我正在寫第二人稱只是因爲它容易，對你而言。擴展一個像命名空間（C++）的現有類？
你正在使用遊戲引擎，並且真的希望特定的引擎類有一個新的方法來做'bla'。但是你不想將你的'遊戲'代碼傳播到'引擎'代碼中。
所以你可以用你的一個新方法從它派生出一個新的類，並把這個代碼放在你的'遊戲'源代碼目錄中，但也許還有另一種選擇？
所以這在C++語言中可能是完全非法的，但你起初想過，「也許我可以通過我自己的頭添加一個新的方法到現有的類，包括'父'頭和一些特殊的語法。是可能的，例如...「
假設你不能跨多個頭聲明一個類的方法（並且你非常確信你不能），那麼其他的選擇是什麼支持「中間件/引擎/庫」和「應用程序」之間的清晰分界，你想知道嗎？
我唯一的問題就是，「你添加的功能需要成爲一個成員函數，還是它可以是一個自由函數？」如果你想要做的事情可以使用類的現有接口來解決，那麼唯一的區別就是語法，你應該使用一個自由函數（如果你認爲這很「醜陋」，那麼......吸引它並繼續前進， C++不是爲monkeypatching設計的）。
如果您試圖弄清楚班級內部的一些問題，這可能意味着原始班級缺乏靈活性（它並沒有爲您提供足夠的信息，無法滿足公衆的需求接口）。如果是這樣的話，也許原來的課程可以「完成」，然後你又回到了一個免費的功能。
如果沒有絕對的，將工作，你只是必須有一個成員函數（如原始的類提供你想在保護成員，而你沒有自由修改原來的接口）...只有採用繼承和成員函數實現。
如需深入討論（並解構std::string'），請查看Guru of the Week "Monolith" class article。
聽起來像你想要Ruby mixins。不確定在C++中有什麼關係。我認爲你必須做繼承。
編輯：你可能會把一個朋友的方法和混合使用它，但我認爲你會開始打破你的封裝不好。
添加好友功能需要類定義本身，這違背了這個問題的目的，因爲你只需要添加的功能本身就存在着的修改。 – 2008-10-23 03:38:55
您可能能夠在同一個命名空間中添加一個簡單的非朋友非成員函數，而這樣既能保護封裝，並增強你的類。事實上，這是* C++中的方法。 – paercebal 2008-10-23 07:00:02
聽起來像'行爲'關係，這不適合繼承（謹慎使用！）。
一個選項是一個組合工具類，它通過使用指向它的指針實例化「引擎」的某個實例。
如果實用程序類包含在另一個類，增加了功能，並暴露了全新的界面，可能會奏效。假設你是在加入如果您需要訪問類的內部來實現你的功能，那麼無論是類的鼻祖做錯了或者你並不需要訪問類的內部... – 2008-10-23 03:34:38
你可以做類似於COM的事情，其中基類支持一個QueryInterface（）方法，它可以讓你請求一個具有該方法的接口。這在C++中實現相當簡單，您本身不需要COM。
你也可以「假裝」成爲一種更加動態的語言，並有一系列回調作爲「方法」，並且使用模板或宏調用它們並在其餘部分之前將「this」推入堆棧參數。但它會是瘋了:)
或分類Objective C。
在C++中有擴展類架構（而不是單一類）的概念方法，但它不是一種隨便的行爲，需要提前計劃。抱歉。
雖然我沒有看到這方面的繼承有什麼問題。
聽起來像是一個典型的繼承問題。除非我將代碼放在「引擎增強」目錄中&在您的體系結構中包含該概念。
如果新方法將使用現有的公共接口來實現，那麼可以說它更加面向對象，因爲它是一個單獨的函數而不是方法。至少，斯科特梅耶斯認爲這是事實。
爲什麼？因爲它提供了更好的封裝。 IIRC認爲類接口應該定義對象所做的事情。助手樣式函數是可以用對象完成的事情，而不是對象必須執行的事情。所以他們不屬於班級。如果他們在課堂上，他們可以不必要地訪問私人成員，從而擴大該成員的隱藏範圍，從而增加私人成員以任何方式變化時需要觸及的代碼行數。
當然，如果你想訪問受保護的成員，那麼你必須繼承。如果你想要的方法需要每個實例的狀態，但不能訪問受保護的成員，那麼你可以根據喜好繼承或複合 - 前者通常更簡潔，但是如果關係不是真的「是」 。
寫在第二人稱聽起來像一個編程語言課程的考試問題。有人應該做一個研究，看看第一人稱，第二人稱或第三人稱問題是否能產生更好的答案... – Mnebuerquo 2008-10-23 03:27:26
你被分配做這樣的研究。你將如何繼續？ – Spike0xff 2012-09-26 16:48:12