1. 契約としてのインターフェース: アーキテクチャの基礎
Java（に限らず）においてインターフェースは単なるメソッドの集合ではありません。これは契約です。すなわち、そのインターフェースを実装するあらゆるクラスが特定の振る舞いを提供するという約束です。インターフェースは実装すべき内容を定め、方法は定めません。
なぜ重要なのか?
- コードのレイヤ分離。 インターフェースによって「何をするか」と「どのようにするか」を分離できます。たとえば PaymentService というインターフェースがあれば、クレジットカード、PayPal、仮想通貨などの異なる実装で支払いを処理できますが、pay() を呼び出す側のコードはその詳細を気にする必要がありません。
- 柔軟性と拡張性。 既存のコードを変更せずに新しい実装を追加できます。これは大規模チームや長寿命のプロジェクトで特に重要です。
- テスト容易性。 インターフェースがあれば、本番実装に手を触れずにテスト用（モック）の実装へ容易に差し替えられます。
例: サービス層とDAO
ビジネスアプリの古典的な例を見てみましょう。ユーザーを扱うためのインターフェースがあるとします:
public interface UserRepository {
User findById(int id);
void save(User user);
}
状況に応じて、このインターフェースはさまざまに実装できます:
- DatabaseUserRepository — ユーザーをデータベースに保存する。
- InMemoryUserRepository — ユーザーをメモリに保存する（テストに便利）。
- FileUserRepository — ユーザーをファイルに保存する。
ユーザーを扱うコードは、インターフェースのみに依存します:
public class UserService {
private final UserRepository userRepository;
// 依存関係をコンストラクタで注入
public UserService(UserRepository userRepository) {
this.userRepository = userRepository;
}
public void registerUser(User user) {
userRepository.save(user);
}
}
これで、サービスのコードを変更せずに UserRepository の実装を容易に差し替えられます。
2. Dependency Injection（依存性注入）とインターフェースの役割
Dependency Injection（DI、依存性注入）とは、依存関係（例: インターフェースの実装）を、通常はコンストラクタやセッターを通じて外部からオブジェクトへ渡すアーキテクチャ手法です。これにより、柔軟でテストしやすく拡張しやすいアプリケーションを構築できます。
なぜDIにインターフェースが重要なのか?
実装をコード内にベタ書きしてしまうと、差し替えが困難になります。インターフェースを用いれば、メインのコードを変更せずに任意の実装を差し込めます。
依存性注入の例
public interface NotificationSender {
void send(String message);
}
public class EmailNotificationSender implements NotificationSender {
@Override
public void send(String message) {
System.out.println("Email を送信: " + message);
}
}
public class SmsNotificationSender implements NotificationSender {
@Override
public void send(String message) {
System.out.println("SMS を送信: " + message);
}
}
// NotificationSender を利用するクラス
public class NotificationService {
private final NotificationSender sender;
public NotificationService(NotificationSender sender) {
this.sender = sender;
}
public void notifyUser(String message) {
sender.send(message);
}
}
これで NotificationService を簡単にテストできます。たとえば実際の送信者の代わりに「スタブ」を渡すことが可能です。
3. デザインパターンとインターフェース
インターフェースはアーキテクチャだけの話ではなく、デザインパターンにも不可欠です。多くのパターンはインターフェースなしには実現できません。代表的なものを見ていきましょう。
Observer（オブザーバ）
Observer は、あるオブジェクト（被観測者）が、自身の状態変化を他のオブジェクト（オブザーバ）に通知できるようにするパターンです。
UML図（簡略）:
+------------------+ +------------------------+
| Subject |<------->| Observer |
+------------------+ +------------------------+
| +addObserver() | | +update() |
| +removeObserver()| +------------------------+
| +notifyObservers()|
+------------------+
コード例:
import java.util.ArrayList;
import java.util.List;
// オブザーバのインターフェース
public interface Observer {
void update(String event);
}
// サブジェクトのインターフェース
public interface Subject {
void addObserver(Observer observer);
void removeObserver(Observer observer);
void notifyObservers(String event);
}
// サブジェクトの実装
public class NewsAgency implements Subject {
private List<Observer> observers = new ArrayList<>();
@Override
public void addObserver(Observer observer) {
observers.add(observer);
}
@Override
public void removeObserver(Observer observer) {
observers.remove(observer);
}
@Override
public void notifyObservers(String event) {
for (Observer observer : observers) {
observer.update(event);
}
}
}
// オブザーバの実装
public class NewsReader implements Observer {
private String name;
public NewsReader(String name) {
this.name = name;
}
@Override
public void update(String event) {
System.out.println(name + " はニュースを受け取りました: " + event);
}
}
// 実行用のメインクラス
public class ObserverExample {
public static void main(String[] args) {
// "ニュースエージェンシー"（サブジェクト）を作成
NewsAgency agency = new NewsAgency();
// オブザーバを作成
Observer alice = new NewsReader("Alisa");
Observer bob = new NewsReader("Bob");
// オブザーバを購読させる
agency.addObserver(alice);
agency.addObserver(bob);
// ニュースを配信
agency.notifyObservers("新しい Java バージョンがリリースされました!");
// 1人のオブザーバを解除してもう一つニュースを配信
agency.removeObserver(bob);
agency.notifyObservers("購読者向けの次のニュース");
}
}
結果:
Alisa はニュースを受け取りました: 新しい Java バージョンがリリースされました!
Bob はニュースを受け取りました: 新しい Java バージョンがリリースされました!
Strategy（ストラテジ）
Strategy は、クライアントコードを変更せずに実行時にアルゴリズム（振る舞い）を選択できるようにするパターンです。
UML図（簡略）:
+------------------+
| Context |
+------------------+
| -strategy: Strat.|
| +setStrategy() |
| +execute() |
+------------------+
|
v
+------------------+
| Strategy |<-------------------------+
+------------------+ |
| +execute() | |
+------------------+ |
^ |
| |
+------------------+ +------------------+ |
| ConcreteA | | ConcreteB |---+
+------------------+ +------------------+
| +execute() | | +execute() |
+------------------+ +------------------+
コード例:
public interface PaymentStrategy {
void pay(int amount);
}
public class CreditCardPayment implements PaymentStrategy {
@Override
public void pay(int amount) {
System.out.println("支払い " + amount + " ルーブル（クレジットカード）");
}
}
public class PaypalPayment implements PaymentStrategy {
@Override
public void pay(int amount) {
System.out.println("支払い " + amount + " ルーブル（PayPal）");
}
}
public class OnlineStore {
private PaymentStrategy paymentStrategy;
public void setPaymentStrategy(PaymentStrategy strategy) {
this.paymentStrategy = strategy;
}
public void checkout(int amount) {
paymentStrategy.pay(amount);
}
}
// 使い方:
OnlineStore store = new OnlineStore();
store.setPaymentStrategy(new CreditCardPayment());
store.checkout(1000);
store.setPaymentStrategy(new PaypalPayment());
store.checkout(500);
結果:
支払い 1000 ルーブル（クレジットカード）
支払い 500 ルーブル（PayPal）
Command（コマンド）
Command は、要求をオブジェクトとしてカプセル化し、操作をパラメータとして渡せるようにするパターンです。
コード例:
public interface Command {
void execute();
}
public class LightOnCommand implements Command {
@Override
public void execute() {
System.out.println("ライトがオンになりました!");
}
}
public class LightOffCommand implements Command {
@Override
public void execute() {
System.out.println("ライトがオフになりました!");
}
}
public class RemoteControl {
private Command command;
public void setCommand(Command command) {
this.command = command;
}
public void pressButton() {
command.execute();
}
}
// 使い方:
RemoteControl remote = new RemoteControl();
remote.setCommand(new LightOnCommand());
remote.pressButton(); // ライトがオンになりました!
remote.setCommand(new LightOffCommand());
remote.pressButton(); // ライトがオフになりました!
4. アーキテクチャでインターフェースを使う利点
- 疎結合（Low Coupling）。 コードは具体的な実装ではなくインターフェースにのみ依存します。これにより、差し替え・テスト・拡張が容易になります。
- テスト容易性。 unitテストを書く際に、本番実装をテスト用（mock/stub）へ簡単に置き換えられます。
- 拡張性。 既存コードを変更せずに新しい実装を追加できます — 開放/閉鎖の原則（OCP）。
- 並行開発。 共通のインターフェースがあれば、複数のチームが独立してシステムの異なる部分を実装できます。
- アーキテクチャの柔軟性。 新しいパターンやアプローチを取り入れやすくなります。
5. アーキテクチャでインターフェースを使う際の典型的な誤り
エラー No. 1: 実装への強い結合。
具体的なクラスを至る所で直接使っていると、実装の変更のたびに多くの箇所を書き換える必要が出てきます。常に「インターフェースに対して」プログラミングすることを心がけましょう。
エラー No. 2: 巨大すぎるインターフェース（God Interface）。
インターフェースはコンパクトで、単一の責務を担うべきです。何でもかんでも1つのインターフェースに詰め込むのは避けましょう。実装が重く複雑になってしまいます。
エラー No. 3: テスト容易性の利点を無視。
依存関係の差し替えにインターフェースを使わないと、テストは遅く信頼性が低くなりがちです。特に実データベースやネットワークに接続する場合は顕著です。
エラー No. 4: 実装は複数あるのにDIを使わない。
インターフェースの実装を複数用意しても、コードに特定実装をハードコードしてしまえば柔軟性は失われます。依存性注入（DI）を活用しましょう！
GO TO FULL VERSION