抽象化はプログラミングにとって重要です。あなたはどのように抽象的である必要があるかを慎重に選択する必要があります。プログラマーの熱意は、しばしば本当に有用なものよりも抽象度を高めます。これを示す一つの兆候は、実際にコードを含まないクラスを作成し、抽象的なものを提供する以外は何もしないクラスを作成する場合です。これの魅力は理解できますが、コードの簡潔さの価値は抽象化の価値に対して測定されなければなりません。時折、熱狂的な理想主義者が間違いを犯したことがあります。プロジェクトの開始時には、抽象的に思える多くのクラスが定義され、発生する可能性のあるすべての事態を処理すると推測します。プロジェクトが進行し、疲労が入り込むにつれて、コード自体が乱雑になります。関数本体は、必要以上に長くなります。空のクラスは、文書化の負担であり、プレッシャー下では無視されます。抽象化に費やされたエネルギーが、物事を短く簡単に保つために費やされたなら、最終的な結果はより良いものになりました。これは投機的プログラミング*の一形態です。私は、[Paul Grahamによる[ 'Succinctness is Power'（http://www.paulgraham.com/power.html）の記事を強くお勧めします。
情報隠蔽やオブジェクト指向プログラミング*などの便利なテクニックに関連したドグマがあります。これらの技術は、1つのコードを抽象的なものにし、変化を予期する。私は個人的には、多くの投機的なコードを生成すべきではないと思います。たとえば、変数自体がエクスポーズされないように、ミュータラとアクセサの背後にあるオブジェクトの整数変数を非表示にして、それに対する小さなインターフェースだけを受け入れるスタイルは容認されています。これにより、呼び出しコードに影響を与えずにその変数の実装を変更することができ、非常に安定したAPIを公開しなければならないライブラリライターにとってはおそらく適切です。しかし私は、私のチームがコーリングコードを所有しているので、呼び出し元を簡単にコーラーと同じように再コーディングすることができるので、これの利点がその言語のコストを上回るとは思わない。 4つまたは5つの余分なコード行は、この投機的な利益のために支払うための重い代償です。
移植性にも同様の問題があります。コードを別のコンピュータ、コンパイラ、ソフトウェアシステム、またはプラットフォームに移植するか、簡単に移植する必要がありますか？ポータブルではない、短くて簡単に移植できるコードは、長い移植可能なコードよりも優れていると思います。特定のDBMSに固有のデータベースクエリを作成するクラスなど、ポータブルでないコードを指定された領域に限定することは比較的簡単であり、確かに良い考えです。