🐦

SOLID原則単一責任の原則

2024/05/26に公開

アーキテクチャ

設計

SOLID原則

tech

はじめに

SOLID原則の単一責任の原則についてまとめてみました。
ここでは単一責任の原則についての説明、単一責任の原則ができていないと発生するリスクなどを述べています。

単一責任の原則

単一責任の原則はモジュールは一つの事柄に対して責務を持つこと
この時の注意点としてはモジュールは一つの機能のみに責務を持つのではなく、一つのユーザー、ステークホルダー、ドメインなどに対して責務を持つことを指します。
ここではユーザーやステークホルダーなどを総じて事柄としています。
単一責任の原則に反してモジュールが複数の事柄に責務を持っていた場合にアプリケーションにどの様な影響が後述していきます。

単一責任の原則に反することへの影響

前提としてオブジェクト指向ではクラスまたはオブジェクトを再利用し組み合わせてアプリケーションを構築していきます。この時モジュールが単一責任の原則に反し複数の事柄に責務を持つと以下の問題が発生します。

改修による他機能への影響

複数の振る舞いを持つモジュールは多機能なことから様々な機能で再利用されることがあります。
この時に上記のモジュールを改修した場合、このモジュールを利用している改修対象の機能以外の他の機能に影響を与える可能性があります。
また、改修する際に他の機能への影響の有無を調査するコストが発生します。

コンフリクト

複数の振る舞いを持つことからモジュールの変更はリアルタイムで頻繁に行われる可能性があります。
複数の開発者によって変更が行われるとコンフリクトが発生しコンフリクトを解消するためのコストが発生します。
複数の振る舞いが複雑に絡み合っている場合、コンフリクトの解消の仕方次第では障害が発生する可能性があります。

単一責任の原則を満たしているモジュールとは

ドメインオブジェクト

ドメインオブジェクトは業務の事柄を落とし込んだオブジェクトです。
例えば社員オブジェクトの場合は社員名や社員番号などの社員に関することを扱うオブジェクトになり、この社員オブジェクトには商品の情報を取り扱うことはないです。
この時、社員オブジェクトは社員のことのみに責務を持っている状態となります。
そのためドメインオブジェクトは単一責任の原則を満たしていると考えています。

モジュールを一言で説明できること

オブジェクト指向設計実践ガイドによれば、単一責任の原則を満たしているオブジェクトは１文で説明できるとのことです。
しかし、このとき１文に「〜と〜」、「〜または〜」などは含まれている場合は二つまたは二つ以上の事柄に対して責任を持っているため、単一責任の原則を満たしていません。
前述の社員オブジェクトを例に説明しますと、社員オブジェクトは「社員に関することのみを扱うモジュール」と説明ができ単一責任の原則を満たしていると判断できます。
しかし、この社員オブジェクトに商品の情報を取り扱うように改修すると社員オブジェクトの説明は「社員と商品に関することを扱うオブジェクト」になり二つのことに責務を持つことになり単一の責任原則を満たしているとは言えなくなります。

おわりに

単一責任の原則を意識して開発することで保守性の高いアプリケーションになることが分かりました。
単一責任の原則ではモジュールが責務を持つ事柄をチーム内で明確にし共有をしないとファイル数が多くなったり、コードの重複が発生するのではないかと感じました。
上記を防ぐ為にモジュールが責任を持つ事柄を明確にし共有するためにドメイン駆動開発を利用するのも一つの手段なのではないかと考えています。