オブジェクト指向プログラミングにおいて重要な考え方としてSOLIDの原則があります。基本的にはポリモーフィズムを駆使することが重要になってくるかと思います。今回はそんなSOLID原則について簡単にまとめました。(あくまで個人的なまとめですので間違いなどあるかもしれません)

単一責任

例えば税金計算クラスがあったとします。

新しく税金の表示フォーマットのために"%"を付けて返すようにしたいという要望が出てきました。そのため、税金計算クラスにgetTaxPercentメソッドのようなものを追加して、8%という文字列で返せるようにしました。

public class CalcTax {
    public int calc(){
        return 10;
    }
    public String getTaxPercent(){
        return Integer.valueOf(calc()) + "%";
    }
}

今度は、"%"だけでなくて"かっこ()"をつけて返すようにしたいという要望が出てきました。そのため、税金計算クラスにgetTaxFormatメソッドのようなものを追加して、(8)という文字列で返せるようにしました。

public class CalcTax {
    public int calc(){
        return 10;
    }
    public String getTaxPercent(){
        return Integer.valueOf(calc()) + "%";
    }
    public String getTaxParentheses(){
        return "(" + Integer.valueOf(calc()) + ")";
    }
}

この時、税金計算クラスは計算という責任以外にも表示という責任も負ってしまっています。そのため表示に関わる処理は別のクラスに分離して単一責任を守るようにします。

public class PrintTax {
    public String getTaxPercent(int tax){
        return Integer.valueOf(tax) + "%";
    }
    public String getTaxParentheses(int tax){
        return "(" + Integer.valueOf(tax) + ")";
    }
}

そしてこのクラスを利用する時は以下のようになります

CalcTax calcTax = new CalcTax();
int tax = calcTax.calc();

PrintTax printTax = new PrintTax();
System.out.println(printTax.getTaxParentheses(tax));

オープンクローズドの原則

これは拡張に対してオープンで、変更に対してクローズしている状態の事を言います。これだけでは意味がわかりません。（私はわかりませんでした）

機能の追加は既存コードを変更することなく簡単に行うことができる。ということです。これにはインターフェースとポリモーフィズムを利用します。

例えば消費税の計算で、今までは8%でしたが10%に変更するという要望が出てきました。加えて軽減税率であれば8%で計算する必要があります。

また、今後税率が変動する可能性も考慮しないといけません。例えば机は10%ですが水は8%の軽減税率対象商品であるとします。

public class Desk {
    public final String name;
    public Desk(String name){
        this.name = name;
    }
}

public class Water {
    public final String name;
    public Water(String name){
        this.name = name;
    }
}

ものすごく単純ですが利用してみます。この時にインスタンスに応じて税率を切り替えています。

public void test_(){
        Desk desk = new Desk("机");
        int tax = getTax(desk);
        System.out.println("税金額は%dです".formatted(tax));
    }

    private int getTax(Object obj){
        if(obj instanceof Desk){
            return 10;
        }
        if(obj instanceof Water){
            return 8;
        }
        return 0;
    }

しかしこれでは拡張する時に（商品を追加する）コードを修正（変更）する必要がでてきます。つまりオープンクローズドの原則を破っています。

そこでインターフェースを作成してこの原則を守ります

public interface Item {
    int getTax();
}

これを実装します

public class Desk implements Item{
    public final String name;
    public Desk(String name){
        this.name = name;
    }

    @Override
    public int getTax() {
        return 10;
    }
}

public class Water implements Item{
    public final String name;
    public Water(String name){
        this.name = name;
    }

    @Override
    public int getTax() {
        return 8;
    }
}

今まで利用していたgetTaxメソッドに着目すると、拡張に対して開いていて変更に対して閉じていることがわかります。

public void test_(){
    Desk desk = new Desk("机");
    int tax = getTax(desk);
    System.out.println("税率は%dです".formatted(tax));
    Water water = new Water("おいしい水");
    tax = getTax(water);
    System.out.println("税率は%dです".formatted(tax));
}

private int getTax(Item item){
    return item.getTax();
}

リスコフの置換原則

これはサブクラスのオブジェクトはスーパークラスに置き換えても、期待通りに動作しないければいけないという原則です。例えばコップというクラスがあったとします。コップは温めることと冷やすことができます。それを継承したマグカップクラスは、とてもイイ感じに温めてくれます(雑ですが...)

public class Cup {
    public void warm(){
        System.out.println("温めました");
    }
    public void cool(){
        System.out.println("冷やしました");
    }
}

マグカップクラス

public class MagCup extends Cup{
    @Override
    public void warm(){
        System.out.println("とても温かく温めました");
    }
}

さて、新しくグラスコップを作ろうとしました。しかしこれは温めることができないので、温める際には例外とするようにしました。

public class GlassCup extends Cup{
    @Override
    public void warm(){
        throw new RuntimeException("温めることはできません");
    }
}

これがリスコフの置換原則に違反しています。以下を実行すると例外になります

public void test_(){
    List<Cup> cups = List.of(
        new MagCup(),
        new GlassCup()
    );
    cups.forEach(Cup::warm);
}

スーパークラスのオブジェクトとして動作させることができませんでした(スーパークラスの期待通りに動作しなければ例外でなくてもリスコフの置換原則に違反します)

インターフェースを作って解決してみます。温め可能であることを表すインターフェースです

public interface Microwavable {
    void warm();
}

カップからは温めるという機能を外しました

public class Cup {
    public void cool(){
        System.out.println("冷やしました");
    }
}

そしてマグカップはMicrowavableインターフェースを実装します

public class MagCup extends Cup implements Microwavable{
    @Override
    public void warm(){
        System.out.println("とても温かく温めました");
    }
}

これでリスコフの置換原則を守りました

public void test_(){
    List<Microwavable> cups = List.of(
        new MagCup()
        // new GlassCup()
    );
    cups.forEach(Microwavable::warm);
}

インターフェース分離の原則

インターフェースが巨大になり過ぎると、どんどんクラスの責務が大きくなっていくので、インターフェースはシンプルにしていくのが良いです。つまり大きなインターフェースは小さなインターフェースに分離していきます。

例えば電子レンジというインターフェースがあったとします。チンができるという機能です。

public interface Microwave {
    void chin();
}

これを実装した製品があります

public class MicrowaveProduct implements Microwave{
    @Override
    public void chin() {
        System.out.println("温めました");
    }
}

新しくオーブン機能が付いたオーブンレンジを作ろうとします。この時に、既存の電子レンジにオーブン機能をつけることを実施しました。

public interface Microwave {
    void chin();
    void oven();
}

新商品であるオーブンはチンもオーブン調理もすることができます。

public class OvenMicrowaveProduct implements Microwave{
    @Override
    public void chin() {
        System.out.println("温めました");
    }

    @Override
    public void oven() {
        System.out.println("オーブン調理をしました");
    }
}

しかし、これではオーブン機能が使えない電子レンジも、オーブン機能のメソッドを実装する必要がでてきます。

public class MicrowaveProduct implements Microwave{
    @Override
    public void chin() {
        System.out.println("温めました");
    }

    @Override
    public void oven() {
        throw new RuntimeException("オーブン機能は使えません");
    }
}

インターフェースがクラスに求めることが多くなり過ぎてはいけない。そのためオーブン機能は別のインターフェースとして分離します。

public interface Oven {
    void oven();
}

複数の実装クラスを持つことができるので以下のようにすれば問題ありません

public class OvenMicrowaveProduct implements Microwave,Oven{
    @Override
    public void chin() {
        System.out.println("温めました");
    }

    @Override
    public void oven() {
        System.out.println("オーブン調理をしました");
    }
}

インターフェースが肥大化してしまった場合は、インターフェースを分離してクラスが持つ責務を適切な量に切り分けてあげることが重要です。以下は動作します

public void test_(){
    List<Microwave> product = List.of(
            new MicrowaveProduct(),
            new OvenMicrowaveProduct()
    );
    product.forEach(Microwave::chin);

    Oven ovenProduct = new OvenMicrowaveProduct();
    ovenProduct.oven();
}

依存関係逆転の原則

個人的に一番大事だと思っている原則です。

この原則は実装ではなく抽象に依存するようにプログラミングすることです。例えばOracleデータベースを利用したアプリケーションが、バージョンアップでPostgreにも対応したとします。ここでUserOracleRepositoryのようなクラスと、UserPostgreRepositoryのようなクラスを用意する必要がでてきたとします。

public class UserOracleRepository {
    public void access(){
        System.out.println("OracleDatabaseに接続しました");
    }
}

public class UserPostgreRepository {
    public void access(){
        System.out.println("PostgreDatabaseに接続しました");
    }
}

そして二つのインスタンスを利用できるようにクラスを修正したとすると、機能の拡張に対して閉じいる状態になっているので、オープンクローズドの原則を破ることになります。

public class UserService {
    public final String Setting = "oracle";

    private final UserOracleRepository oracleRepository;
    private final UserPostgreRepository postgreRepository;
    public UserService(UserOracleRepository oracleRepository, UserPostgreRepository postgreRepository){
        this.oracleRepository = oracleRepository;
        this.postgreRepository = postgreRepository;
    }

    public void save(){
        if(Setting.equals("oracle")){
            this.oracleRepository.access();
        }
        else if(Setting.equals("postgre")){
            this.postgreRepository.access();
        }else{
            throw new RuntimeException("設定に誤りがあります");
        }
    }
}

ここでは利用するコンポーネントがOracleやPostgreという具象クラスに依存していることが原因なので、インターフェースを作成してインターフェースに依存させるようにします。 OracleやPostgreに接続する具象クラスが、Repositoryというインターフェースを実装することで、ロジックがインターフェースに依存できるようになります。すると拡張に対して空いているし、変更に対して閉じている状態にもなります。

public interface Repository {
    void access();
}

それぞれがRepositoryインターフェースを実装する

public class UserOracleRepository implements Repository{
    @Override
    public void access(){
        System.out.println("OracleDatabaseに接続しました");
    }
}

利用する際には具象クラスではなくて、インターフェースに依存するようにする

public class UserService {
    private final Repository repository;
    public UserService(Repository repository){
        this.repository = repository;
    }
    public void save(){
        this.repository.access();
    }
}

実際にはDIなどで依存関係を解決しますが、これは抽象に対してプログラミングをしているからこそ、その実装を切り替えることができます

public void test_(){
    UserService userService = new UserService(new UserOracleRepository());
    userService.save();
}

クリーンアーキテクチャでは、依存関係逆転の原則を利用して制御の流れを一方通行にするなどしています。