ソフトウェアインターフェイスは、さまざまな”レベル”でさまざまな種類のインターフェイスを指すことがあります。 また、オブジェクト指向プログラムでは、アプリケーション内のオブジェクトはメソッドを介して対話する必要があります。

in practiceEdit

設計の重要な原則は、デフォルトですべてのリソースへのアクセスを禁止し、明確に定義されたエントリポイント、すなわちインターフ ソフトウェアインターフェイスは、コンピュータリソース（メモリ、CPU、ストレージなど）へのアクセスを提供します。 ソフトウェアによるそのようなリソースへの直接アクセス（すなわち、うまく設計されたインターフェイスを介してではない）は、機能性と安定性のため

ソフトウェアコンポーネント間のインターフェイスは、定数、データ型、プロシージャの型、例外仕様、およびメソッドシグネチャを提供できます。 場合によっては、パブリック変数もインターフェイスの一部として定義されます。

ソフトウェアモジュールAのインタフェースは、そのモジュールの実装とは別に意図的に定義されています。 後者には、インターフェイスで記述されているプロシージャとメソッドの実際のコード、および他の”プライベート”変数、プロシージャなどが含まれています。 Aと対話する別のソフトウェアモジュールB、たとえばクライアントAは、公開されたインターフェイスを介してのみ強制的に実行されます。 この配置の実用的な利点の1つは、Aの実装を同じインターフェイスの別の実装に置き換えると、Bが失敗してはならないことです。Aが内部でインターフェイスの要件をどのように満たしているかは、インターフェイスの仕様にのみ関係するBとは関係ありません。 （リスコフ置換原理も参照のこと。)

オブジェクト指向languagesEdit

一部のオブジェクト指向言語、特に完全な多重継承を持たない言語では、インターフェイスという用語は、データを含まないがメソッドシグネチャとしてビヘイビアを定義する抽象型を定義するために使用されます。 そのインタフェースに対応するすべてのメソッドのコードとデータを持ち、そのように宣言するクラスは、そのインタフェースを実装すると言われます。 さらに、単一継承言語であっても、複数のインターフェイスを実装することができ、したがって同時に異なるタイプのものにすることができます。

インターフェイスは型定義であり、オブジェクトを交換できる場所（関数やメソッド呼び出しなど）では、交換されるオブジェクトの型は、特定のクラスを指定するのではなく、実装されたインターフェイスまたは基本クラスのいずれかによって定義できます。 このアプローチは、そのインターフェイスを実装する任意のクラスを使用できることを意味します。 例えば、ダミーの実装を使用して、最終的な実装が利用可能になる前に開発を進行させることができる。 別のケースでは、テスト中に偽の実装またはモック実装が置換されることがあります。 このようなスタブ実装は、開発プロセスの後半で実際のコードに置き換えられます。

通常、インターフェイスで定義されたメソッドにはコードが含まれていないため、それ自体を呼び出すことはできません。 “Stackpush()pop()FastStackGenericStack—最初は高速で固定サイズのデータ構造を使用し、2番目はサイズ変更可能なデータ構造を使用しますが、いく

インターフェイスには多くのメソッドを含めることができますが、それらは一つだけ、またはまったく含まれていない場合もあります。 たとえば、Java言語は、単一のread()ReadableBufferedReaderFileReaderInputStreamReaderPipedReaderStringReaderSerializableのようなマーカインターフェイスにはメソッドがまったく含まれておらず、リフレクションを使用して汎用処理にランタイム情報を提供

interfaceEditへのプログラミング

インターフェイスの使用は、インターフェイスへのプログラミングと呼ばれるプログラミングスタイルを可能にします。 このアプローチの背後にある考え方は、内部実装の詳細ではなく、使用されるオブジェクトのインターフェイスにプログラミングロジックを基 インターフェイスへのプログラミングは、実装の詳細への依存を軽減し、コードをより再利用可能にします。

このアイデアを極端に押し進めると、制御の反転は、作業を実行するために使用されるインターフェイスの特定の実装でコードを注入するためのコ