【Clean Architecture】プログラミングパラダイム

Page content

はじめに

この記事は私が「Clean Architecture 達人に学ぶソフトウェアの構造と設計」を読んだ際の備忘録です。
本記事を読んで興味を持たれたら是非読んでみてください。

本記事では、参考書籍にて語られている「プログラミングパラダイム」に関わる部分についてまとめています。

プログラミングパラダイム

参考書籍では以下の三つのパラダイムについて述べられています。

  • 構造化プログラミング
  • オブジェクト指向プログラミング
  • 関数型プログラミング

これらのパラダイムでは、それぞれ有害になりやすい命令を禁止することでより安全な実装を促しています。

構造化プログラミング

禁止されたもの

構造化プログラミングではgoto文が禁止されました。
それまでgoto文によって行われていた制御は、if文などの「選択」とwhile文などの「反復」に置き換えられました。

生じた利点

構造化プログラミングを行うと、モジュールをテスト可能な単位まで再帰的に分割できるようになります。
プログラムを適切に分割して単体テストすることで、想定されるバグを事前に発見できるようになります。

オブジェクト指向プログラミング

禁止されたもの

参考書籍では、オブジェクト指向プログラミングでは関数ポインタが禁止されたと述べられています。
オブジェクト指向に関して語られる概念の中にポリモーフィズムがありますが、以前は関数ポインタを用いて同じ振る舞いを再現していたらしいです。
関数ポインタを用いたポリモーフィズムの代わりに、より安全にポリモーフィズムを実装できる手段が提供されました。

生じた利点

オブジェクト指向プログラミングのポリモーフィズムでは、インターフェイスを用いてソースファイルの依存関係を制御フローと逆にすることができます。
この手法は「依存関係逆転」と呼ばれ、設計の原則の一つであるSOLID原則の内、「依存関係逆転の原則」という原則で使用されます。

関数型プログラミング

禁止されたもの

関数型プログラミングでは代入が禁止されました。
変数の値は宣言時に確定し、以降の値変更は原則行えません。

生じた利点

代入を禁止すると並行処理で発生する競合状態や並行更新などの問題が発生しなくなります。
一般的なプログラミングでは代入を完全に禁止することは困難ですが、「イベントソーシング」という手法によって可能になる場合があります。

おわりに

次回はモジュールレベルの設計原則である「SOLID原則」について書く予定です。
来月中には記事を上げますのでお楽しみください。