抽象化が多すぎると悪いことはありますか？

プログラマーとして、私たちの目標は、与えられたドメインモデルとビジネスロジックを適切に抽象化することだと思います。しかし、この抽象化はどこで止めるべきですか？抽象化とそのすべての利点（柔軟性、変更の容易さなど）と、コードとそのすべての利点の理解の容易さとの間でトレードオフを行う方法。

私は過度に抽象化されたコードを書く傾向があり、それがどれほど良いのかわかりません。私はよく、2つの部分で構成されるマイクロフレームワークのようなものを書く傾向があります。

1. マイクロフレームワークに接続されたマイクロモジュール：これらのモジュールは、単一ユニットとして理解、開発、および保守が容易です。このコードは基本的に、要件で説明されている機能的な機能を実際に実行するコードを表しています。
2. 接続コード; 今ここに私は問題があると信じています。このコードは、時には非常に抽象化されていて、最初は理解しにくいため、複雑になる傾向があります。これは、純粋な抽象化、現実のベース、および提示されたコードで実行されるビジネスロジックにすぎないという事実により発生します1。この理由から、このコードはテスト後に変更されることはありません。

これはプログラミングの良いアプローチですか？多くのモジュールで非常に断片化されたコードの変更が非常に理解しやすく、抽象化POVからの変更のないコードは非常に複雑であるということですか？すべてのコードが均一に複雑である（つまり、コード1がより複雑で相互にリンクされ、コード2がより単純である）ため、コードを見ている人は合理的な時間内にそれを理解できますが、変更は高価であるか、上記のソリューションは優れています「コードの変更」は理解、デバッグ、変更が非常に簡単であり、「コードのリンク」は一種の困難です。

注：これはコードの可読性に関するものではありません！1と2のコードはどちらも読み取り可能ですが、2のコードにはより複雑な抽象化があり、コード1には単純な抽象化があります。

TC ++ PL4の最初の言葉：

コンピュータサイエンスのすべての問題は、インダイレクションの層が多すぎるという問題を除き、別のレベルのインダイレクションによって解決できます。–デビッドJ.ウィーラー

（David Wheelerは私の論文アドバイザーでした。重要な最後の行のない引用は、「コンピューターサイエンスの最初の法則」と呼ばれることもあります。）

はい、間違いなく。問題は、完璧な抽象化はないということです。抽象化が置かれるレイヤーの詳細はすべて理由があるため、多くのことを簡素化できますが、ある時点でその複雑さが必要でなければ、そもそもそこにはないでしょう。そしてそれは、ある時点で、すべての抽象化が何らかの形で漏洩することを意味します。

そして、そこが本当の問題です。抽象化が失敗した場合、記述したコードと実際に行われていることの間にレイヤーを重ねるほど、問題が発生する可能性のある場所が増えるため、問題を見つけて修正することが難しくなります。そして、レイヤーが多いほど、それを追跡するために知る必要があります。

そのとおり。

プログラミングを説明するのに使用したい例えは、テーラーの例えです。スーツを作るとき、優れたテーラーは常に衣服の戦略的な場所に少量の布地を残し、全体的な形や構造を変えずに衣服を出し入れできるようにします。

グッドテーラーは、たまたま第3の腕を伸ばしたり妊娠したりした場合に備えて、縫い目に大量の布地を残さないでください。間違った場所にある材料が多すぎると、フィット感が悪くなり、衣服を着たときに、余分な布地が通常の使用の邪魔になります。小さな布地や衣服に破れがちであり、着用者の体格のわずかな変化に対処するために変更することはできず、衣服の座り方に影響を与えます。

おそらくいつか、私たちの良い仕立て屋はドレスをとてもきつくするように任せられます。そして、おそらく私たちのGood Tailorは、スタイルとフィット感が快適さと拡張性に次ぐマタニティウェアを作るように求められています。しかし、これらの特別な仕事のいずれかを引き受ける前に、優れたテーラーは、それらの目標を達成するために行われている妥協点を全員に気付かせるのに十分賢明です。

時にはこれらの妥協が正しい道であり、人々は彼らの結果を喜んで受け入れます。しかし、ほとんどの場合、それが最も重要であるところを少し残すというアプローチは、認識された利益よりも重要です。

したがって、これを抽象化に関連付けます。絶対に多すぎるほど抽象化の層が多すぎる可能性があります。プログラマーの真の芸術は、私たちのテーラーの友人のように、最も重要な場所に少しだけ残すことです。

トピックに戻って。

通常、コードの問題は抽象化ではなく、依存関係です。あなたが指摘したように、それは問題である個別のオブジェクトを接続するコードです。なぜなら、それらの間には暗黙的な依存関係があるからです。ある時点では、物事間のコミュニケーションは具体的である必要がありますが、通常、そのポイントがどこにあるかを判断するには推測が必要です。

「マイクロ」と呼ばれることは、通常、オブジェクトレイアウトを過度に細分化したことを示しており、おそらくDataの同義語としてTypeを使用している可能性があります。また、物事が少ないということは、それらの間の通信に必要な依存関係が少なくなることを意味します。

この理由から、私はシステム間の非同期メッセージングの大ファンです。互いにではなく、メッセージに依存する2つのシステムになります。通信システム間の密結合を緩和します。その時点で、システム間の依存関係が必要な場合は、適切な場所に依存するビットがあるかどうかを考慮する必要があります。そして、あなたがしてはいけないことがよくあります。

最後に、複雑なコードは複雑になります。多くの場合、それを回避する方法はありません。ただし、依存関係の少ないコードは、さまざまな外部状態に依存するコードよりも理解しやすいです。

私たちの目標は、特定のドメインモデルとビジネスロジックを適切に抽象化することです。

私は別の見方をしています：私たちの目標はビジネス上の問題を解決することです。抽象化は、ソリューションを整理するための単なるテクニックです。別の答えは、服を作る仕立て屋のアナロジーを使用しています。私が考えたい別のアナロジーがあります：スケルトンです。コードはスケルトンに似ており、抽象化はボーン間のジョイントです。ジョイントがない場合は、まったく動かず、役に立たない単一のボーンで終わるだけです。しかし、関節が多すぎると、それだけでは立ち上がれないずさんなゼリーの山になってしまいます。コツは正しいバランスを見つけることです-動きを可能にするのに十分な関節ですが、実際に定義された形状や構造がないほどではありません。