やってみてください、猛烈なロットオブコードですよ。インスタンス化可能なクラス「CFoo: public InterfaceCFoo」は、InterfaceCFoo *privateContextフィールドを持ち（1対1の関係を作る）、ファクトリーで生成・削除し、全てのメソッドをデリゲートし、CFoo*がこの<->privateContextを所々参照できるように翻訳する必要があります。これは「手作業で夕日を落とす」、つまり継承を委任に置き換え、その場で夕日を落とすということです。
試しに使ってみてください。インスタンス化可能なクラス「CFoo: public InterfaceCFoo」は、InterfaceCFoo *privateContextフィールドを持ち（1対1の関係を作る）、ファクトリーで生成・削除し、全てのメソッドをデリゲートし、同時にCFoo*がこの<->privateContextをあちこちで参照するように変換しなければなりません。これは「手作業で夕日を落とす」、つまり継承を委任に置き換え、その場で夕日を落とすということです。
が、うまくいきません :-)
やってみてください、猛烈なロットオブコードですよ。インスタンス化可能なクラス「CFoo: public InterfaceCFoo」は、InterfaceCFoo *privateContextフィールドを持ち（1対1の関係を作る）、ファクトリーで生成・削除し、全てのメソッドをデリゲートし、CFoo*がこの<->privateContextを所々参照できるように翻訳する必要があります。これは「手作業で夕日を落とす」、つまり継承を委任に置き換え、その場で夕日を落とすということです。
ファクトリーを通して作成し、通常の方法で削除します。デリゲーションが必要かどうかは、ライブラリの内容がどのように使われることを想定しているかで決まります。もし、それ自体が仕事をするクラスを提供しているならば、何もデリゲーションする必要はなく、ただインターフェースのメソッドを呼び出せばいいのです。
ちなみに、Android/Javaでは、カーネルクラスで似たようなことがあります。多重継承ができないため、オブジェクトにデリゲートを挿入し、そのメソッドのラッパーメソッドを作らなければならないのです。C'est la vie.
試しに使ってみてください。インスタンス化可能なクラス「CFoo: public InterfaceCFoo」は、InterfaceCFoo *privateContextフィールドを持ち（1対1の関係を作る）、ファクトリーで生成・削除し、全てのメソッドをデリゲートし、同時にCFoo*がこの<->privateContextをあちこちで参照するように変換しなければなりません。これは「手作業で夕日を落とす」、つまり継承を委任に置き換え、その場で夕日を落とすということです。
言葉も、シラフの人は半分も飲まないと何を言っているのかわからない。:)そして、このOOPや中国語の読み書きは、単純なデータ交換をするために作られたもので、手続きレベルでは些細なことで実現できるのです...。
悪質なOOPコーダーが存在するのは、OOPそのものに罪はない。一般的なOOPには何の問題もありません。OOPに関するあなたの意見は完全に間違っています。
悪質なOOPコーダーが存在するのは、OOPそのものに罪はない。一般的なOOPには何の問題もありません、あなたのOOPに対する意見は完全に間違っています。
その歴史を知らないんですね。
直接の妨害行為で何度も出入り禁止に。だから、彼の好戦的な無知に反応してはいけない。
一般的に、OOPには何の問題もありません。OOPに対するあなたの意見は完全に間違っています。
OOPについて、なぜか無知とは呼ばれない人たちの有名な批判的引用をwikiから紹介します。
解放の意味も込めて、OOPについて、なぜか無知とは言われない人たちの有名な批判的引用をwikiから引用しておきます。
そして、その3人：1950年生まれのステパノフ、1934年のヴィルト、そして同じく古代のキルア（彼の著書は1998年に出版された）は、2017年にそれを繰り返すことを非常に恥ずかしく思っていることでしょう。
彼らが言ったことは、もう思い出すのも恥ずかしいくらい昔のこと。C++コンパイラは、少なくとも2桁は頭が悪く、最適化においてより原始的でした。実際、そこには最適化の痕跡はなかった。当時（90年代初頭）、私もアセンブラをたくさん書いていましたが、「C/C++は遅い」というのは同じ考えでした。
引用を抜き出した形でリンクを行うのは、私の役目ではありません。しかも、あなたはすでにこのスレッドで、極度の鈍感さと攻撃的な無知を示すことに成功しています。
Renat Fatkhullin:
このスレッドですでに、あなたの極端な鈍感さと攻撃的な無知を示すことができたのです。
まとめてみましょう。ここで、OOPに関する私の主な仮説を述べます。10の投稿で「OOPは便利なテキストラッパーとして、あるいは実行時の初期化時に最小限の使用しか意味をなさない...」とありますね。
そして、こちらは独立した専門家による同様の意見と詳細なコードレベルの証明による根拠ある意見です。
http://rainman-rocks.livejournal.com/122876.html
"最終的な結論はこうだ。
オブジェクト指向プログラミングが有効である最大の理由は、モジュール性と宣言性を提供する手段を含んでいることである。モジュール化と宣言性こそが、開発効率を高めるツール、すなわち「銀の弾丸のようなもの」なのです。方法論を選択する際に重視すべきは、これらの点である。OOPだけを目標にしてはいけない。"
要約するとここで、OOPに関する私の基本的な仮説があります。10の投稿で「OOPは便利なテキストラッパーとして、あるいは実行時の初期化で最低限使われる場合にのみ意味を持つ...」とありました。
そして、こちらは独立した専門家による同様の意見と詳細なコードレベルの証明による根拠ある意見です。
http://rainman-rocks.livejournal.com/122876.html
"最終的な結論はこうだ。
オブジェクト指向プログラミングが有効である最大の理由は、モジュール性と宣言性を提供する手段を含んでいることである。モジュール化と宣言性こそが、開発効率を高めるツール、すなわち「銀の弾丸のようなもの」なのです。方法論を選択する際に重視すべきは、これらの点である。OOP自体が目的であってはならない。"
自分の意見が最低限受け入れられるように、個人的に実施したプロジェクトを見せてください。引用されたリンク先も理解できないのかー、出力も含めてただのOOPの頌歌だ。
すべてのソフトウェアは、実質的に90％以上がOOPで書かれています（ドライバについてはナンセンスなことを言わないでください）。実際、OOPなしで大規模なプロジェクトを書き、そして維持することは不可能です。そして、ビジネスとなると「たかが包み紙」なんて言葉は通用しないのです。ソフトウェア開発は、古くからある老舗のビジネスです。
理解せずにOOPに文句を言う人は、最近のC++コンパイラが何をやっているのか分かっていない。最終的なコードには、OOPの面影はまったく残っていないことが多いのです。もちろん、C++の話です。
個人的に実現したプロジェクトを見せることで、自分の意見を最低限受け入れてもらえるようにする。引用したリンク先も理解できないのか、結論も含めてただのOOPの頌歌だ。
この記事の主旨について、何が書いてあるかわからないように、もう一回引用させてください。
「このように、OOPは構造化手続き型プログラミングの代替を目指したものの、結局はほとんど同じものに戻ってしまったが、ただ派手な包装を施しただけである。この作戦に意味はあったのだろうか......」という疑問も出てくる。
申し訳ありませんが、論理と因果関係が理解できません。なぜ、自分の意見が最低限考慮されるように、実現したプロジェクトが 必要なのでしょうか。通常、文明的な議論では、意見の根拠と妥当性そのものがあれば十分です。
そうでなければ、ある人がプロジェクトを実施したならば、その人のその後の発言は、最初はすべて万人に受け入れられなければならないが、実際には、すべて理路整然としていないかもしれないし、同じくプロジェクトを実施した他の専門家の意見と矛盾しているかもしれない、という不合理な結論に達してしまうのだ。
繰り返すが、自慢することはカルマに悪いので、あまり慎み深いとは言えない。
つまり、プロジェクトが ない、つまり経験がないのです。
同時に、かつて経験した（その時代の）人たちの古い言葉を引き出そうとする、経験も忘れては いけません。ご自身の経験がないため、一昔前の破廉恥な発言は通用しないことに気づかないのでしょう。それはうまくいかず、その時代特有の妄想に過ぎなかった。こういう妄想は、もう思い出すのも恥ずかしいくらいです。
また、引用したリンク先に書かれていることの本質がよく理解できていない。OOPは松葉杖よりも優れており（松葉杖はOOPを使わずにOOPを模倣しようとするもの）、使用しなければならない」と書いてあるのに、言葉を掠め取って誤解しているのですね。