抽象化：問題の解決と一般的な解決策の間の戦争[終了]

プログラマーとして、私は自分のプログラムをできるだけ抽象的で一般的なものにするジレンマに陥っています。

そうすることで、通常、コードを再利用し、再び発生する可能性のある（または発生しない）問題のより一般的な解決策を得ることができます。

それから私の頭の中のこの声は、問題のダミーを簡単に解決するだけだと言います！なぜあなたが必要以上に多くの時間を費やしますか？

実際、私たちは皆、この疑問に直面してきました。そこでは、抽象化があなたの右肩にあり、Solve-it-愚かな人が左に座っています。

どれを、どのくらいの頻度で聞くべきですか？これに対するあなたの戦略は何ですか？すべてを抽象化する必要がありますか？

どれを、どのくらいの頻度で聞くべきですか？

必要になるまで抽象化しないでください。

たとえば、Javaでは、インターフェイスを使用する必要があります。それらは抽象化です。

Pythonにはインターフェイスがなく、Duck Typingがあり、抽象化の高いレベルは必要ありません。だからあなたはそうしません。

これに対するあなたの戦略は何ですか？

3回作成するまで抽象化しないでください。

1回は-まあ-1回です。解決して先に進みましょう。

2回は、ここにパターンがある可能性があることを示しています。またはありません。偶然かもしれません。

3回目はパターンの始まりです。今では偶然を超えています。これで正常に抽象化できます。

すべてを抽象化する必要がありますか？

いや

実際、正しい種類の抽象化を行っているという絶対的な証拠が得られるまで、何も抽象化しないでください。「3つの繰り返しのルール」がなければ、役に立たない方法で無駄に抽象化されたものを書くことになります。

通常、そうすることでコードを再利用できます

これは多くの場合間違っている仮定です。抽象化はまったく役に立ちません。それはひどく行うことができます。したがって、必要になるまで実行しないでください。

ああ、ヤグニ。最も乱用されたプログラミングの概念。

コードを汎用化することと、余分な作業を行うことには違いがあります。コードを疎結合にし、他のことを行うのに簡単に適応させるために余分な時間を費やすべきですか？絶対に。不要な機能の実装に時間を費やすべきですか？いいえ。まだ実装されていない他のコードでコードを動作させるのに時間を費やすべきですか？いや

ことわざにあるように、「おそらく動作する可能性のある最も単純なことを行う」。事は人々がいつも簡単と簡単を混同するということです。シンプルさには手間がかかります。しかし、努力する価値はあります。

船外に行けますか？もちろん。しかし、私の経験では、ほとんどの企業は既に持っている以上の「今すぐやろう」という態度を必要としています。ほとんどの企業には、事前に物事を考える人がもっと必要です。さもなければ、彼らは常に誰も何もする時間がなく、誰もがいつも急いでいて、誰も何もすることができないという自立した問題を抱えています。

このように考えてください：あなたのコードが何らかの形で再び使用される可能性が高いです。ただし、そのように正しく予測することはできません。したがって、コードをクリーンで抽象的で、疎結合にします。ただし、まだ存在しない特定の機能を使用してコードを機能させようとしないでください。たとえそれが将来存在することを知っていても。

三段論法：

1. 一般性は高価です。

2. あなたは他の人のお金を使っています。

3. したがって、一般性の費用は利害関係者に正当化される必要があります。

後で利害関係者のお金を節約するために、より一般的な問題を本当に解決しているのか、それとも不必要に一般的なソリューションを作成するのが知的挑戦であると思うのかを自問してください。

一般性が望ましいと判断された場合、他の機能と同様に設計およびテストする必要があります。実装した汎用性が仕様で必要な問題をどのように解決するかを示すテストを作成できない場合は、気にしないでください！設計基準を満たさず、テストできない機能は、誰も信頼できない機能です。

そして最後に、「可能な限り一般的」というものはありません。議論のためだけに、C＃でソフトウェアを作成するとします。すべてのクラスにインターフェースを実装させますか？すべてのクラスは抽象基底クラスであり、すべてのメソッドは抽象メソッドですか？それはかなり一般的ですが、「可能な限り一般的」にはほど遠いです。これにより、サブクラス化によってメソッドの実装を変更できます。サブクラス化せずにメソッドの実装を変更したい場合はどうなりますか？実際には、すべてのメソッドを別のメソッドに変更できるように、セッターを使用して、すべてのメソッドをデリゲート型のプロパティにすることができます。しかし、誰かがさらにメソッドを追加したい場合はどうでしょうか？ここで、すべてのオブジェクトは拡張可能でなければなりません。

この時点で、C＃を放棄してJavaScriptを採用する必要があります。しかし、あなたはまだ十分に一般的なものに近づいていません。誰かがこの特定のオブジェクトに対するメンバー検索の動作を変更したい場合はどうなりますか？代わりに、すべてをPythonで記述する必要があります。

一般性の向上とは、多くの場合、予測可能性を放棄し、テストコストを大幅に増加させて、実装された一般性が実際のユーザーのニーズを満たすことを確実にすることを意味します。それらの費用は、それを支払っている利害関係者への利益によって正当化されますか？おそらくそうです。利害関係者と話し合うのはあなた次第です。私の利害関係者は、完全に不必要で非常に高価な一般性を追求するために静的型付けを放棄するつもりはまったくありませんが、おそらくあなたはそうです。

明確にするために、一般化されたものを作成し、抽象化を実装することは、まったく異なる2つのことです。

たとえば、メモリをコピーする関数を考えます。

この関数は、4バイトのコピー方法を隠す抽象化です。

int copy4Bytes（char * pSrc、char * pDest）

一般化すると、この関数は任意のバイト数をコピーします。

int copyBytes（char * pSrc、char * pDest、int numBytesToCopy）

抽象化は再利用に役立ちますが、一般化により多くの場合に抽象化が有用になります。

より具体的に質問に関連して、抽象化はコードの再利用の観点からのみ有用ではありません。多くの場合、正しく行われれば、コードがより読みやすく保守しやすくなります。上記の例を使用すると、コードcopyBytes（）をざっと読んだり、配列を反復処理してデータを1インデックスずつ移動したりする場合に、読みやすく理解しやすいものは何でしょうか。抽象化は、私の意見では、コードを扱いやすくするための自己文書を並べ替えることができます。

私自身の経験則として、コードの一部の意図を正確に説明する適切な関数名を思い付くことができれば、再度使用するかどうかに関係なく、そのための関数を記述します。

この種の物に対する一般的なルールは、ゼロ、ワン、インフィニティです。つまり、書いているものを複数回必要とする場合、それがさらに何度も必要になると仮定して、一般化することができます。このルールは、何かを最初に書くときに抽象化に煩わされないことを意味します。

このルールのもう1つの正当な理由は、コードを初めて作成するときに、抽象化する対象が1つしかないため、必ずしも何を抽象化するかがわからないことです。マーフィーの法則は、最初に抽象コードを記述する場合、2番目の例には予期しなかった違いがあることを意味します。

Eric Lippertは、彼の記事で将来設計を証明する 3つのことを指摘しています。あなたがそれに従うなら、あなたは良い状態になると思います。

最初：時期尚早の一般性は高価です。

2番目：常に問題領域にあり、クラスの関係が変わらないものだけをモデルに表現します。

第三：ポリシーをメカニズムから遠ざけます。

コーディングの理由、プロジェクトの目的によって異なります。コードの価値が具体的な問題を解決するものである場合、それを完了させて次の問題に進みたいと思うでしょう。コードの将来のユーザー（自分を含む）が簡単にできるようにするためにできる迅速で簡単なことがあれば、ぜひとも、合理的な配慮をしてください。

一方、記述しているコードがより一般的な目的に役立つ場合があります。たとえば、他のプログラマーのためにライブラリを作成している場合、さまざまなアプリケーションでライブラリを使用します。潜在的なユーザーは不明であり、ユーザーが何を望んでいるかを正確に尋ねることはできません。しかし、あなたはあなたのライブラリを広く有用にしたいです。そのような場合、一般的なソリューションをサポートするためにより多くの時間を費やすことになります。

私はKISSの原則の大ファンです。

最善の解決策ではなく、求められていることを提供することに重点を置いています。私は悲惨になったので、完璧主義（およびOCD）を手放さなければなりませんでした。

ここで、Abstractionは右肩にあり、Solve-it-st-upidは左側にあります。

「愚かな解決」には同意しませんが、「賢く解決する」ことができると思います。

よりスマートなもの：

• 複数のケースをサポートできる複雑な汎用ソリューションを作成する
• 手で問題を解決し、保守が容易で、短いとeffecientコードを書くと、そのことができますされ、拡張将来的にはIFことが必要です。

デフォルトの選択肢は2番目の選択肢です。世代の必要性を示すことができなければ。

一般化されたソリューションは、複数の異なるプロジェクト/ケースで使用されるものであることがわかっている場合にのみ使用してください。

通常、一般化されたソリューションは、「コアライブラリコード」として最適です。