GoLang における SOLID の原則 - 単一責任原則 (SRP)

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

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

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

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

SOLID と GoLang

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

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

単一責任原則 (SRP)

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

上記には、userService という構造体があります。これには 2 つのプロパティがあります。db はリレーショナル データベースとの通信を担当し、amqpChannel

は RabbitMQ メッセージング サービスとの通信を可能にします。

UserService は Create というメソッドを実装します。このメソッド内では、受信したユーザー情報をデータベースに保存し、そのデータを RabbitMQ に公開します。

userService の Create メソッドの役割は 1 つではなく 2 つあることがわかります。データベースへの情報の保存と RabbitMQ キューへのメッセージのパブリッシュです。

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

保守が難しい: ユーザー データのシリアル化方法など、要件の 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 ブログ - 単一責任の原則

以上がGoLang における SOLID の原則 - 単一責任原則 (SRP)の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。