抽象化の原理（コンピュータプログラミング）

ソフトウェア工学とプログラミング言語理論において、抽象化の原則（または抽象化の原則）とは、プログラミング言語またはソフトウェアライブラリによって提供される抽象化を利用して、プログラム内の情報の重複（通常はコードの重複に重点を置く）を可能な限り削減することを目的とした基本的な格言である。^[1]この原則は、プログラマへの推奨事項として述べられることもありますが、プログラミング言語が抽象化を使用することが望ましい理由を自ら理解していることを前提として、プログラミング言語の要件として述べられることもあります。この原則の起源は定かではなく、何度か再発明されており、時には異なる名前で、わずかな変化を伴って再発明されています。

プログラマーへの推奨事項として読むと、抽象化の原則は「同じことを繰り返さない」(DRY) 原則として一般化できます。これは、一般的に情報の重複を避けること、およびソフトウェア開発プロセスに関わる人的労力の重複を避けることを推奨しています。

プログラマーへの推奨事項として、ベンジャミン・C・ピアースが「型とプログラミング言語」 （2002年）で定式化した抽象化の原則は次のように述べられています（強調は原文のまま）。^[2]

プログラム内の重要な機能は、ソース コード内の 1 か所にのみ実装する必要があります。類似の機能が別々のコード部分で実行される場合、さまざまな部分を抽象化して 1 つにまとめると効果的です。

プログラミング言語の要件として、David A. Schmidt が「型付きプログラミング言語の構造」（1994 年）で定式化した抽象化の原則は、次のように述べられています。^[3]

意味的に意味のある任意の構文クラスの句に名前を付けることができます。

抽象化の原則については、いくつかの書籍で言及されています。そのいくつかと、簡潔な場合はその定式化を以下に挙げます。

• アルフレッド・ジョン・コール、ロナルド・モリソン (1982) S-algol によるプログラミング入門: 「[抽象化] を言語設計に適用すると、言語内の意味的に意味のあるすべての構文カテゴリを定義し、それらの抽象化が可能になります。」^[4]
• ブルース・J・マクレナン（1983）プログラミング言語の原則：設計、評価、実装：「何かを複数回記述することを避け、繰り返しパターンを排除する」^[5]
• Jon Pearce (1998) Schemeにおけるプログラミングとメタプログラミング：「構造と機能は独立しているべきである」^[6]

この原則はオブジェクト指向プログラミングのデザインパターンで中心的な役割を果たしているが、このテーマに関するほとんどの著作ではこの原則に名前が付けられていない。Gang of Four の著書『デザインパターン』では、「ここでの焦点は、変化する概念をカプセル化することであり、これは多くのデザインパターンのテーマである」と述べられている。この文は他の著者によって「変化するものを見つけてカプセル化する」と言い換えられている。^[7]

今世紀、この原則は「一度だけ」というスローガンの下、エクストリームプログラミングで再発明されました。この原則の定義は、初登場時には「重複したコードなし」とかなり簡潔でした。 ^[8]その後、ソフトウェア開発の他の問題にも適用できるものとして詳しく説明されました。「自動化する価値のあるプロセスはすべて自動化します。同じタスクを何度も実行する必要がある場合は、スクリプト化します。」^[9]

抽象化の原則は、抽象化を容易にするためのメカニズムの文脈で述べられることがよくあります。制御抽象化の基本的なメカニズムは、関数またはサブルーチンです。データ抽象化には、さまざまな形式の型ポリモーフィズムが含まれます。データ抽象化と制御抽象化を組み合わせることができるより複雑なメカニズムには、クラス、ポリタイプなどを含む抽象データ型があります。複雑なシナリオで重複を減らすことができるより豊富な抽象化の探求は、プログラミング言語の研究と設計の原動力の 1 つです。

経験の浅いプログラマーは、プログラムに抽象化を過剰に導入しがちです。抽象化は、一度しか使用されません。^[要出典] この問題を強調する補完的な原則は、「You Ain't Gonna Need It」であり、より一般的にはKISS 原則です。

コードは通常改訂される可能性があるため、抽象化の原則に従うとコードのリファクタリングが必要になる場合があります。 ^[要出典]コードを書き直す労力は、一般的に、抽象化によって得られる将来の利益の見積もりに対して償却する必要があります。これを管理する経験則は、 Martin Fowlerによって考案され、3 のルールとして普及しました。これは、コードが 2 回以上コピーされた場合、つまり 3 つ以上のコピーが存在する場合は、抽象化する必要があるというものです。

「同じことを繰り返さない」、または「DRY 原則」は、関連するコードが必然的に層間である程度重複し、通常は異なる言語で実行される、多層アーキテクチャのコンテキストで開発された一般化です。実際的には、ここでの推奨事項は、コード ジェネレーターやデータ変換などの自動化ツールを利用して、繰り返しを回避することです。^{[引用が必要]}

コードの最適化に加えて、プログラミングにおける抽象化レベルの階層的/再帰的な意味は、ハードウェア通信層間のインターフェース、つまり「抽象化レベル」や「抽象化レイヤー」とも呼ばれるインターフェースにも当てはまります。この場合、抽象化レベルはインターフェースと同義であることが多いです。たとえば、シェルコードや高レベル言語と低レベル言語間のインターフェースを調べると、抽象化レベルはオペレーティングシステムのコマンド (たとえば C 言語) からレジスタや回路レベルの呼び出しやコマンド (たとえばアセンブリ言語やバイナリ言語) に変わります。この例では、抽象化レベル間の境界またはインターフェースはスタックです。^[10]