この記事は？
SOLIDのS(単一責任の原則)について、理解を深める為の記事です。
なるべくシンプルで、簡単に理解できるように整理していきます。
出典として、wiki様の記事を使用させていただいております。
想定読者
- 単一責任の原則がなんなのかは知ってるけど、いまいち腹落ちしてない人
責任と目的について
原則について、wikiには以下のよう記載されています。
マーティンは、責任とは変更する理由であるとし、
モジュールを変更する理由は、ひとつだけであるべきであると定めた。
モジュールを変更する理由をひとつだけにする目的は、モジュールの堅牢性を高めることである。
整理すると、
- 「責任」 とは 「変更する理由」 である
- 「モジュールの堅牢性を高めること」 が目的である
ということのようです。
コードで書いてみる
より理解を深めるために、例の部分を実際にコードで書いてみたいと思います。
周りにruby書ける人が多いので、rubyで考えてみます。
悪い例（wikiより）
例えば、報告書を作成して、描画するようなモジュールを想定する。
まず、レポートの内容を変更したい場合に、このモジュールを変更する必要がある。
また、レポートの形式を変更したい場合にも、このモジュールを変更する必要がある。
さらに、これらのふたつの変更は、それぞれ異なるアクターによるものである。
これをコードで表現してみます。
# Reportクラス
# 報告書を作成して、描画するモジュール
# レポートの内容を変更したい場合に、このモジュールを変更する必要がある。
# レポートの形式を変更したい場合にも、このモジュールを変更する必要がある。
class Report
# レポートを作成する
def initialize(contents)
@contents = contents
end
# レポートを描画する
def render
render_report @contents
end
private
# 描画する処理
def render_report(contents)
# do render
end
end
# クライアント向けレポートを生成するクラス(Actor)
class ClientReporter
def report(text)
Report.new(text).render
end
end
# ユーザー向けレポートを生成するクラス(Actor)
class UserReporter
def report(text)
Report.new(text).render
end
end
何がダメなのか？
wikiには以下のように記載されています。
よって、このモジュールは、変更する理由、すなわち責任を複数持っており、
これらを結合する設計は、単一責任の原則に反している。
仮に、レポートの内容の変更に伴って、報告書を作成する実装を修正する場合、
報告書を描画する処理にも影響が及ぶ可能性がある。
ちょっと日本語が難しいですね。実際にどんな状態かコードと共に考えてみます。
例では「レポートの内容の変更に伴って」と記載されているので、ここでは以下のような追加要件があったと場合を想定して考えてみます。
- ユーザー向けレポートの場合、フッターにオススメ情報メッセージを追加する
上記要件を追加するため、Reportクラスの実装を変更してみましょう。
# Reportクラス
class Report
def initialize(contents)
@contents = contents
end
# レポートを描画する
def render
render_report(@contents + get_recommendations) # オススメ情報フッターを追加する
end
private
# 描画する処理
def render_report(contents)
# do render
end
# オススメ情報を取得
def get_recommendations
# do get recommentations
end
end
無事ユーザー向けレポートの場合、フッターを追加する機能を実装することができました。
しかし、どうでしょうか？
これでは、クライアント向けのレポートにもオススメ情報が表示されるようになってしまいました。
ここでwikiの例に記載されていた内容を改めて確認してみます。
まず、レポートの内容を変更したい場合に、このモジュールを変更する必要がある。
また、レポートの形式を変更したい場合にも、このモジュールを変更する必要がある。
さらに、これらのふたつの変更は、それぞれ異なるアクターによるものである。
# 記載の通り、異なるアクターによる変更が一つのモジュールに集約されてしまっていましたね。
よって、このモジュールは、変更する理由、すなわち責任を複数持っており、
これらを結合する設計は、単一責任の原則に反している。
# すなわち、その状態が”原則に反している”と言えるようです。
要すると、
複数のアクターに対する責任は、複数のモジュールに分散しましょう
という理解ができる気がします。（たぶん）
どうすれば良いか？
では原則に則って先ほどのコードを修正してみます。
# Report抽象クラス
class AbsReport
def initialize(contents)
@contents = contents
end
# レポートを描画する
def render
raise "Don't call this method directly."
end
end
# Client向けReporter
class ClientReport < AbsReport
def render
# client向けレンダー処理
end
end
# User向けReporter
class UserReport < AbsReport
def render
# user向けレンダー処理
end
end
こんな感じでしょうか。
各アクターへの責任が、別のReportのサブクラスで持つようになったことで、責任が分散されたと思います。
結論
以上から「単一責任の原則」とは、
- モジュールを使用するアクターが、複数存在する場合に検討する必要がある。
- アクター毎に対する責任は、一つのモジュールに集約するのではなく、分散して実装する。
- そうすることで、他のアクターへの影響を防ぎ、モジュールの堅牢性を高めることができる。
ということだと理解しました。
理解の一助になれれば幸いです。 