オブジェクト指向コードを拡張して、いかなる種類の共有も行わないツールはありますか?たとえば、Cを継承する2つのクラスAとBがある場合、ツールはクラスAとBを調整してCを使用しないようにします。ツールがこれを実行しても、コンパイルして同じ結果が得られると便利です。クラスタイプが動的にチェックされる場合、主な問題は条件付きロジックを調整することだと思います。
これは機械の観点からはまったく無意味ですが、楽しい学術演習になるでしょう。
オブジェクト指向コードを拡張して、いかなる種類の共有も行わないツールはありますか?たとえば、Cを継承する2つのクラスAとBがある場合、ツールはクラスAとBを調整してCを使用しないようにします。ツールがこれを実行しても、コンパイルして同じ結果が得られると便利です。クラスタイプが動的にチェックされる場合、主な問題は条件付きロジックを調整することだと思います。
これは機械の観点からはまったく無意味ですが、楽しい学術演習になるでしょう。
そこにはさまざまなリファクタリングツールがありますが、そのような自動操作を実行するには、かなりのコンテキスト知識と人間の介入が必要になるため、あなたの質問が実用的であるとは思えません。
あなたの例では、AとBがCのメソッドとプロパティを取得するだけでは十分ではありませんが、多くの場合、A(またはB)をメソッドに渡してCのように扱いたい場所があるという事実.または、C を受け取るが、A (または B) の特定の動作が呼び出されるものにそれを渡したい場合があります。その中にあるオブジェクトに対して .DoThing() を呼び出すコレクションを想像してください。
クラスをバラバラにするだけでなく、他のオーバーロードされたすべての関数を、冗長に見えるコードをたくさん持つ必要があります (特に、動作だけでなく、型について)。
興味深い思考実験ですが、おそらくそれは悪い考えの山に入れるべきだと思います。読みやすさ、拡張性、またはパフォーマンスに役立つとは思えません。
これの問題は、A や B ではなく C を使用するコードを扱うのが難しいことです。
public void workWithSomeC( C useThis ) { ... }
OO コードでは、A または B のいずれかをその関数に渡すことができます。A と B に共通点がなくなったら、それはできません。
そのようなコードを複製することで何かが機能するようになると思いますが、なんと恐ろしい考えでしょう ;-)