SOLID原則のリスコフの置換原則(LSP)についてRubyで解説

オブジェクト指向プログラミングにおいて、コードの保守性、可読性、再利用性を高めるために、SOLID原則と呼ばれる5つの重要な設計原則があります。

今回は、このSOLID原則のうち、リスコフの置換原則 (Liskov Substitution Principle, LSP)についてRubyのサンプルコードを用いて解説していきます。

SOLIDとは

SOLIDとは、5つの原則の頭文字を取った略語です。

1. Single Responsibility Principle(SRP): 単一責任原則
2. Open Closed Principle(OCP): オープン・クローズドの原則
3. Liskov Substitution Principle(LSP): リスコフの置換原則
4. Interface Separation Principle(ISP): インターフェース分離の原則
5. Dependency Inversion Principle(DIP): 依存性逆転の原則

リスコフの置換原則 (Liskov Substitution Principle, LSP)とは

リスコフの置換原則は、派生クラスのオブジェクトが基底クラスのオブジェクトと置換可能であるべきだという原則です。

つまり、派生クラスは基底クラスのメソッドと同じ引数/返り値の種類を保証し、基底クラスの代わりに使用できるようにします。

これにより、オープン・クローズドの原則に則ったコードで記載した抽象クラスを引数にとる処理で、抽象クラスに属する具象クラスを別のものに変えたとしても問題なく動作し、クラスの再利用性が高まります。

リスコフの置換原則に違反しているコード

以下のPostとDraftPostクラスを例にします。

class Post
  def initialize(title, content)
    @title = title
    @content = content
  end

  def title
    @title
  end

  def content
    @content
  end

  def publish
    puts "Post published: #{@title}"
    true
  end
end

class DraftPost < Post
  def publish
    raise "Cannot publish a draft post"
  end
end

こちらDraftPostが基底クラスであるPostのpublishメソッドと異なる返り値を返しています。

これでは、Postクラスを期待している箇所で、DraftPostが渡されるとエラーとなります。

これでは、再利用性がなく、DraftPost固有の処理を書かないといけません。

リスコフの置換原則に則ったコード

以下が則ったコードとなります。

class Post
  def initialize(title, content)
    @title = title
    @content = content
  end

  def title
    @title
  end

  def content
    @content
  end

  def publish
    puts "Post published: #{@title}"
    true
  end
end

class DraftPost < Post
  def publish
    puts "Cannot publish a draft post"
    false
  end
end

DraftPostのpublishは基底クラスであるPostと同じくbooleanを返すようになりました。

これにより使う側はPostクラス、DraftPostクラスのどちらが渡されてもエラーとなることなく、問題なく処理を続行することが出来ます。

最後に

リスコフの置換原則を使用することで、クラスの再利用性を高めることが出来ます。

また、他のクラスの機能を使いたいためだけにis-aの関係でないのに継承をしてしまうような初心者が最初やってしまいがちなアンチパターンも避けることが出来ます。

もし継承とすべきか委譲とすべきかの判断に迷った際は、この原則を思い出すことで、適切な判断の助けになるかもしれません。

次回はインターフェース分離の原則(ISP)について記事を書こうと思います。

Author

古川 智大

SNS

X(Twitter)

GitHub