あなたにとって簡単だからという理由だけで、私は二人称で書いています。
あなたはゲーム エンジンを扱っていて、特定のエンジン クラスに 'bla' を実行する新しいメソッドがあることを本当に望んでいます。しかし、「ゲーム」コードを「エンジン」コードに広げたくないでしょう。
したがって、1 つの新しいメソッドを使用してそこから新しいクラスを派生させ、そのコードを「ゲーム」ソース ディレクトリに配置することもできますが、別のオプションがあるのでしょうか?
したがって、これはおそらく C++ 言語では完全に違法ですが、最初は、「「親」ヘッダーといくつかの特別な構文を含む独自のヘッダーを介して、既存のクラスに新しいメソッドを追加できるのではないかと考えました。これは、作業中に可能です。たとえば、名前空間を使用して...」
複数のヘッダーにまたがるクラスのメソッドを宣言できないと仮定すると (そして、宣言できないと確信しています)、「ミドルウェア/エンジン/ライブラリ」と「アプリケーション」の間の明確な分割をサポートする他のオプションは何ですか?不思議？
私の唯一の質問は、「追加された機能はメンバー関数である必要がありますか、それとも無料の関数である必要がありますか？」です。クラスの既存のインターフェイスを使用して実行したいことを解決できる場合、唯一の違いは構文です。無料の関数を使用する必要があります（「醜い」と思われる場合は、それを吸い上げて次に進みます。 C ++はモンキーパッチ用に設計されていません）。
クラスの内部の根性を理解しようとしている場合は、元のクラスに柔軟性がないことを示している可能性があります（パブリックインターフェイスから必要なことを実行するための十分な情報が公開されていません）。その場合は、元のクラスを「完了」して、その上に無料の関数を追加することができます。
それがまったく機能せず、メンバー関数が必要な場合（たとえば、元のクラスが取得したい保護されたメンバーを提供し、元のインターフェイスを変更する自由がない場合）...継承とメンバー関数の実装。
詳細な議論（および'の脱構築）については、この今週の達人「モノリス」クラスの記事をstd::stringチェックしてください。
新しいメソッドが既存のパブリック インターフェイスを使用して実装される場合、おそらく、メソッドではなく別の関数である方がオブジェクト指向になります。少なくとも、スコット・マイヤーズはそう主張している。
なんで？それはより良いカプセル化を与えるからです。IIRC では、オブジェクトが行うことをクラス インターフェイスで定義する必要があるという議論が行われています。ヘルパー スタイルの関数は、オブジェクトに対して実行できるものであり、オブジェクト自体が実行する必要があるものではありません。だから彼らはクラスに属していません。それらがクラス内にある場合、プライベート メンバーに不必要にアクセスする可能性があるため、そのメンバーの非表示が拡大し、プライベート メンバーが何らかの形で変更された場合に変更する必要があるコードの行数が増加します。
もちろん、保護されたメンバーにアクセスしたい場合は、継承する必要があります。目的のメソッドがインスタンスごとの状態を必要とするが、保護されたメンバーへのアクセスを必要としない場合は、好みに応じて継承または合成することができます。通常、前者はより簡潔ですが、関係が実際に「ある」ものではない場合、特定の欠点があります。 .
ただし、このコンテキストでの継承の何が問題なのかわかりません。
'acts on' 関係のように聞こえますが、これは継承には適合しません (慎重に使用してください!)。
1 つのオプションは、「エンジン」の特定のインスタンスへのポインタでインスタンス化されることによって、そのインスタンスに作用する合成ユーティリティ クラスです。
私には古典的な継承の問題のように聞こえます。コードを「Engine Enhancements」ディレクトリにドロップし、その概念をアーキテクチャに含めることを除いて。
Ruby ミックスインが必要なようです。C ++に近いものがあるかどうかはわかりません。継承を行う必要があると思います。
編集: フレンド メソッドを入れて mixin のように使用できるかもしれませんが、カプセル化を悪い方法で壊し始めると思います。
基本クラスが QueryInterface() メソッドをサポートし、そのメソッドを持つインターフェイスを要求できる COM のようなことを行うことができます。これは C++ で実装するのはかなり簡単で、COM 自体は必要ありません。
また、より動的な言語であると「ふりをして」、「メソッド」としてコールバックの配列を持ち、テンプレートまたはマクロを使用してそれらを呼び出し、残りのパラメーターの前に「this」をスタックにプッシュする方法を構築することもできます。しかし、それは正気ではないでしょう:)
またはObjective Cのカテゴリ。
C++ でクラス アーキテクチャ (単一のクラスではない) を拡張するための概念的なアプローチがありますが、それは簡単な行為ではなく、事前に計画する必要があります。ごめん。