この概念に慣れていない人のために説明すると、抽象化の反転は、高レベルの構造の上に低レベルの構造を実装することであり、不必要な複雑さと不必要なオーバーヘッドの両方が追加されるため、一般的に悪いことと見なされています。もちろん、これはやや不正確で主観的な定義です。
あなたの意見では、Java や C# など、すべてがクラスの一部である必要があり、ポインターのようなものが公開されていない単一パラダイムの OOP 言語でのプログラミングは、必然的に抽象化の逆転につながりますか? もしそうなら、どのような場合に？
本物のプログラマーならどんな言語でも FORTRAN を書ける
言い換えれば、それは言語ではなく、プログラマーです
単一パラダイムのあらゆるものは、抽象化の第一戒に違反しますが、それを知っている人はほとんどおらず、気にする人はさらに少ないようです。
必要に応じてオーバーライドできない抽象化を作成してはなりません。これにより、コードに醜い抽象化の反転がなくなります。
パラダイムがどうであれ、現実世界の問題を解決するために重要なコードを書き始めると、パラダイムにうまく適合しないものが出てくるでしょう。その 1 つのパラダイムがすべてであると宣言する場合、これは事態が悪化するときです。
いくつかの比喩を組み合わせると、マレットしかない場合、すべてがペグのように見え始め、すべての穴が丸くて、突然四角いペグになってしまい、のこぎりがない場合 (マレットのみ) 、）あなたは自分自身に問題を抱えています。
フリーランチはありません。すべてがトレードオフです。コードを書くのが簡単になればなるほど、他の誰かが読んで維持するのが難しくなり、また、作業している抽象化のレベルより下で問題が発生したときに、あなたや他の誰かがデバッグするのが難しくなります。(そして、最終的にはそうなるでしょう。なぜなら、完璧な抽象化は存在しないからです。
これは、マネージ コード、ガベージ コレクション、JIT コンパイル、および「すべてがオブジェクトである」というフィアットなどの「役立つ」テクノロジとパラダイムの根本的な欠陥です。それらは、その下に到達することを許可されていないベースラインレベルの抽象化を課し、そのレベルより下で何か問題が発生した場合、それに対してできることは何もありません. 修正できないため、悪い抽象化を回避するのに苦労しています。
Java と C# には関数と同等の静的メソッドがあるため、言語によって強制されることはありません。
とは言っても、オブジェクト指向を本当に取得したら、別のスタイルのプログラミングに行きたいという欲求はまったくありませんでした。
単純な OO レイヤーが複雑なものをカバーしている場合は、おそらくコードが問題であることをお勧めします。OO が正しく行われていれば、それは金属に至るまでずっと単純でなければなりません。
JavaやC＃のような言語は、フレームワークに付属するライブラリが非常に豊富であるため、一般的なプログラミングでは別のパラダイムに侵入する必要がないため、具体的な方法でこれに苦しむことはないと思います。
とはいえ、リッチライブラリ自体は抽象化の逆転に悩まされる可能性がありますが、内部実装が隠されているか、キークラスが封印されているため、これらのライブラリを拡張しようとする開発者は、拡張機能を正常に利用するために機能の再実装/複製を強いられることがよくあります。基本クラスライブラリによって提供されるポイント-これは、.Net Frameworkの新しいリリースで脆弱または頻繁に変更される可能性のある機能を公開しないようにするために、基本クラスライブラリの開発者が意識的に選択したため、言語の問題ではありません。 /JDK。
また、.Net Framework / Javaランタイムはどちらも、共通のランタイムの上にある他の言語との相互運用を可能にするため、他のパラダイム（関数型プログラミング、動的言語など）をターゲットにする機能は、単一のパラダイムから脱却するための別のルートを提供することもできます。制約。