ソフトウェア開発の世界では、SOLID 原則により、コードが次のように機能とデータを編成する方法がわかります。

• 変化を許容する
• わかりやすい
• 多くのソフトウェア システムで使用できるコンポーネントの基礎となる

SOLID という用語は、以下に説明する 5 つの設計公準の頭字語です。

(S) 単一責任原則: 「モジュールには、変更する理由が 1 つだけ必要です」
(O) オープン/クローズの原則: 「ソフトウェア アーティファクトは、拡張のためにオープンされなければなりませんが、変更のためにクローズされなければなりません」
(L) リスコフ置換原則: 「派生クラスはその基本クラスによって置換可能でなければなりません」
(I) インターフェイス分離原則: 「クラスは、使用しないインターフェイスやメソッドの実装を強制されるべきではありません」
(D) 依存関係逆転の原則: 「実装ではなく抽象化に依存する」

SOLID と GoLang

SOLID はオブジェクト指向プログラミング用に設計されており、GoLang がこのパラダイムを採用する言語ではないことが知られています。ただし、OOP 方法論を満たすために利用できるリソースを使用できます。たとえば、Go には継承サポートがありませんが、アイデアは合成サポートで補うことができます。同様に、インターフェースを使用して一種のポリモーフィズムを作成できます。

全 5 回シリーズの最初の記事であるこの記事では、私たちが日常的に遭遇する状況に近い例を示して、最初の原則を詳しく説明するつもりです。

単一責任原則 (SRP)

この用語の意味はすでに理解しています。次は、それを GoLang で実装する方法を学びます。
この言語では、この原則を「関数または型は 1 つだけのジョブと 1 つだけの責任を持つ必要がある」と定義できます。次のコードを見てみましょう:

上記には、userService という名前の構造体があります。これには、リレーショナル データベースとの通信を担当する db と、RabbitMQ メッセージング サービスとの通信を可能にする amqpChannel の 2 つのプロパティがあります。

UserService は Create というメソッドを実装します。このメソッド内では、受信したユーザー情報をデータベースに保存し、そのデータを RabbitMQ に公開します。
userService の Create メソッドの役割は 1 つだけではなく、データベースに情報を保存することと、RabbitMQ キューにメッセージをパブリッシュすることの 2 つであることがわかります。

これにより、次のようないくつかの問題が発生する可能性があります:

• 保守が難しい: ユーザー データのシリアル化方法など、要件の 1 つが変更された場合、たとえこれがあなたの主な責任とは関係がない場合でも、Create メソッドのロジックを変更する必要があります。データをデータベースに保存します。
• テストの難易度: Create メソッドには 2 つの異なる役割があるため、それぞれに対してテストを作成する必要がありますが、これは難しくて面倒な作業となる可能性があります。
• 不必要な結合: ユーザー データを RabbitMQ キューにパブリッシュするロジックは、このデータをデータベースに保存するロジックから完全に独立しています。同じメソッド内でこれら 2 つの役割を混在させると、不必要な結合が生じます。

次のコードでは、SRP を尊重するように構造を変更します。それをチェックしてください：

責任を 3 つの異なる部分に分割していることに注意してください。ユーザーをデータベースに永続化するリポジトリ UserRepository、RabbitMQ にメッセージを送信するパブリッシャー UserPublisher、これら 2 つの操作を調整するサービス UserService。

このようにして、各コンポーネントは特定の独立したタスクを担当し、コードのメンテナンスと進化を容易にするだけでなく、これらの各部分を他の部分に影響を与えることなく置き換えたり改善したりすることができます。たとえば、使用するデータベースを変更する必要がある場合は、リポジトリを置き換えるだけです。コミュニケーションの形式を変更する必要がある場合は、発行者を変更するだけです。

2 つの異なるタスクを実行することと、それらの実行を委任することの間には微妙な違いがあることに言及する価値があります。 userService.Create の元の例では、2 つの操作が 1 か所で実行され、単一責任の原則に違反していました。リファクタリング後、実行を別の構造体に委任し、Create メソッドはこのフローの調整のみを担当しました。

この例で SRP を適用するために、他の SOLID 原則のいくつかも実装することになりました。

• インターフェイス分離原則 (ISP): 各インターフェイスは単一の責任を表します。 UserRepository と UserPublisher は両方とも 1 つのメソッドしか持たないインターフェイスであり、それぞれが 1 つの責任を表します。
• 依存関係逆転原則 (DIP): userService 構造体は、具体的な実装ではなく抽象化 (インターフェイス) に依存します。つまり、UserRepository と UserPublisher の特定の実装は認識せず、実装するインターフェイス。
• オープン/クローズド原則 (OCP): userService を変更せずに新しいリポジトリやパブリッシャーを簡単に追加できるため、コードは拡張可能です。

このシリーズの次の記事では、具体的な例を示しながら、それぞれについてさらに詳しく説明します。

また会いましょう!

参考文献:
SOLID: オブジェクト指向設計の最初の 5 原則
Clean Coder ブログ - 単一責任の原則