1. 導入：なぜ抽象化が重要なのか
Javaでの開発において「抽象化」は、コードの再利用性を高め、保守性を維持するための必須スキルです。特に大規模システムでは、共通処理を抽象化しておかないと、仕様変更のたびに似たようなコードを修正する羽目になります。本稿では、abstractクラスとインターフェースの役割を明確にし、現場で迷わない使い分けの基準を解説します。
2. 基礎知識：抽象クラスとインターフェース
抽象クラス（abstract class）は、「〜である（is-a）」という継承関係を表すためのものです。状態（フィールド）を持つことができ、一部の実装を子クラスに強制させつつ、共通処理を再利用させることができます。
一方、インターフェースは「〜ができる（can-do）」という能力を表します。Java 8以降はdefaultメソッドで処理を書けるようになり、Java 9以降はprivateメソッドも使用可能になったため、柔軟性が飛躍的に向上しました。
3. 実装/解決策：現場での使い分け基準
現場での設計ルールとして、まずは「インターフェース」の利用を検討してください。クラスは一つしか継承できませんが、インターフェースは複数実装できるため、拡張性が高いためです。
もし、「複数のクラスで共通のフィールドや、アクセス修飾子がprotectedであるメソッドを定義したい」といった場合にのみ、abstractクラスを選択するのがセオリーです。
4. サンプルプログラム：実践的な実装例
以下は、決済処理を例にした抽象化の実装例です。
// 共通の能力を定義するインターフェース
interface PaymentProcessor {
// 基本的な決済メソッド（実装必須）
void process(double amount);
// デフォルトメソッドで共通のログ出力機能を提供（Java 8〜）
default void logTransaction(double amount) {
System.out.println("決済処理を開始します: " + amount + "円");
validateAmount(amount); // privateメソッドの呼び出し（Java 9〜）
}
// privateメソッドで内部ロジックを隠蔽（Java 9〜）
private void validateAmount(double amount) {
if (amount <= 0) throw new IllegalArgumentException("金額が不正です");
}
}
// 共通ロジックを持つ抽象クラス
abstract class AbstractCreditCardProcessor implements PaymentProcessor {
protected String cardIssuer; // 共通の状態
public AbstractCreditCardProcessor(String cardIssuer) {
this.cardIssuer = cardIssuer;
}
// 抽象メソッド：カード会社ごとの固有処理は子クラスに委譲
protected abstract void connectToGateway();
}
// 具体的なクラス
class VisaProcessor extends AbstractCreditCardProcessor {
public VisaProcessor() { super("VISA"); }
@Override
public void process(double amount) {
logTransaction(amount);
connectToGateway();
System.out.println(cardIssuer + "で決済完了しました。");
}
@Override
protected void connectToGateway() {
System.out.println("VISAゲートウェイに接続中...");
}
}
5. 応用・注意点：現場で陥りやすい罠
1. 継承の乱用: 「何でもかんでも継承」するのは危険です。継承関係が深くなるとコードの追いかけが困難になります。基本は「委譲（Composition over Inheritance）」を優先し、DI（依存性の注入）を組み合わせるのがモダンなJava開発の定石です。
2. defaultメソッドの肥大化: インターフェースのdefaultメソッドにロジックを詰め込みすぎると、テストが困難になり、インターフェースの目的である「契約」が曖昧になります。あくまで補助的な処理にとどめましょう。
3. 多態性（ポリモーフィズム）の活用: サンプルコードのように、インターフェース型で変数を受け取ることで、実行時に具体的なクラスを切り替える設計にしておけば、単体テスト時のモック化も容易になります。
コメント