Joel's Law of Leaky Abstractionsによって軽度の被害を受けたフレンドリーなコーダーと議論しました。新しいフレームワーク/ツールボックスを使用することを彼に納得させるのは非常に困難です。「抽象化されたレベルへの低レベルのアクセスを許可する限り、抽象化は問題ありません」というポイントを提示しようとしています。
例:
音ですか？何か不足していますか？
ありがとう
リーキーな抽象化の記事を読んでわかったことは、抽象化が悪いということではなく、内部で何が起こっているのかを理解し、「予期しない」動作を説明して回避できるようにする必要があるということです。
あなたの友達のプログラムは何ですか? 機械語？:)
Joel のポイント (私が理解しているように) は、複雑さを抽象化することによって、その根底にある複雑さに対するより細かい制御を犠牲にしているということです。些細な場合を除いて、最終的には、抽象化が崩壊する時点で、より細かい制御の粒度にアクセスする必要があります。
したがって、定義上、すべての抽象化は (ほぼ) 漏れやすいものです。
ある程度、彼には一理あります。従来の c/unix 開発は、多かれ少なかれ全体を理解できるほど単純なプラットフォームで機能します。最新のプラットフォームは桁違いに複雑であり、すべてのレイヤーがどのように相互作用するかを理解することははるかに難しく、多くの場合実行不可能です。
漏れやすい抽象化の法則は、主に、フレームワークが根底にある複雑さを適切に管理できない場合に適用されます。フレームワークを判断する方法のいくつかは、その透明性 (舞台裏で何が起こっているかを理解しやすいこと) と、その機能の制限のためにカスタムの回避策にドロップアウトする能力です。
フレームワークが舞台裏で多くの複雑な魔法を実行すると、診断とトラブルシューティングが非常に難しくなり、フレームワークの基盤となるアーキテクチャに不釣り合いに多くの専門知識が必要になることがよくあります。これは、フレームワークによる生産性の向上が、コードのトレーニングとデバッグの余分な労力に吸収されることを意味します。また、フレームワークを学習して自信を持って使用することも困難になります。これは、C プログラミングの友人が慣れていることです。
フレームワークがその制限を回避するのを妨げる場合、それは開発の障害になります。これが頻繁に発生すると、問題を回避するために、コード ベースが封じ込められるか、ますます大規模で乱雑なハッキングによって汚染されます。これは、安定性とデバッグの問題にもつながります。
これらの欠陥のあるフレームワークの例はたくさんあります。MFC は、Win32 の根底にある複雑さを隠蔽できなかったことで非常に有名でした。また、後で手動で変更する必要がある乱雑なコードを生成するウィザードを多用し、そもそもコード ジェネレーターを持つ目的を無効にしました。初期の Java GUI ツールキット (AWT および Swing の初期バージョン) は、開発者がアプリケーションのネイティブなルック アンド フィールを実装するのを妨げていたため、デスクトップ アプリケーションにほとんど取り込まれませんでした。SWT が構築されたのは、Swing のこれらの制限が少なからずあったためです。
しかし、現在 Java は少し成熟しており、その初期の問題のほとんどは最新のフレームワークで修正されていると言えます。J2EE は依然として大規模で複雑なシステムであり、ブラウザで重要なユーザー インターフェイスを開発することもかなりの労力を要します。このプラットフォームに習熟するのは大変な作業です。しかし、それは人間の機知を超えているわけではありません。
すべての抽象化が漏れやすいのは事実だと思いますが、それは必ずしも悪いことではありません。
たとえば、従来の単純な C (C#、Java など) コードでは、通常、ループや ifs などを使用して配列からデータを取得します。
SQL と Linq が同じ問題にアプローチする方法は、よりインテリジェントです。必要なことを言うだけで、マシンがそれを実行する方法を見つけ出します。このようにして、従来の方法からコマンドを特定の順序で並べ替える必要がなくなり、たとえば作業を別の CPU に分割したり、キャッシュをより有効に活用するために並べ替えたりすることができます。
はい、マシンをある程度制御できますが、マシンには1つの大きな利点があります。ユーザー/顧客の場所にあり、その方法でオンデマンドの決定を下すことができます（マルチコアの使用、MMXの利点の使用など） ）。