BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース SOLID原則は最新のソフトウエアアーキテクチャでも重要か?

SOLID原則は最新のソフトウエアアーキテクチャでも重要か?

原文(投稿日:2021/11/27)へのリンク

Daniel Orner氏は先頃、SOLIDの原則は今もなお、最新のソフトウエアアーキテクチャの基盤である、と主張する記事を公開した。記事の中で氏は、ソフトウエア開発の手法は過去20年の間に変化したが、SOLID原則が優れた設計の基礎であることに変わりはない、とした上で、関数プログラミングやマイクロサービスアーキテクチャにも適用可能であることを、例をあげて説明している。

SOLIDは2000年代、Robert C. Martin氏が挙げた5つのソフトウエア設計指針の簡略的表現を表す頭字語である。記事では、これら"SOLIDの原則は、優れたソフトウエアを開発する上で長年に渡って培われた慣習"であり、最新のソフトウエアエンジニアリングプラクティスにも適応可能なものだ、と述べている。

記事の中で氏は、SOLID原則が生まれた以降のソフトウェア業界において、重要な開発パラダイムをいくつか挙げている。動的型付け言語や関数型プログラミングといったパラダイム、あるいはメタプログラミングは、多くの支持を獲得した結果、今日のソフトウェアではごく普通に見られるものになっている。さらに氏は、マイクロサービスやソフトウェア・アズ・ア・サービスがモノリシックなデプロイメントパターンを過去のものにしたことを付け加えた上で、SOLIDの配下にある原則の多くが、かつてほど多くのプログラマによって使用されていない点に言及している。

ソフトウェア設計の他の面は変わっていないにも関わらずだ、と氏は言う。開発者は今でもコードの記述と修正を続けており、モジュールとして編成される点も変わらず、それが意図するユーザベースに従った可視性の定義が必要であることも変わっていない。

そこで氏は、元々のSOLID原理の定義を書き換えて、オブジェクト指向プログラミング(OOP)や関数型プログラミング(FP)、マルチパラダイムプログラミング、場合によってはマイクロサービスベースのシステムにも適用できるようにすることを提案している。

出典: https://stackoverflow.blog/2021/11/01/why-solid-principles-are-still-the-foundation-for-modern-software-architecture/

最初に氏は、単一責任の原則(single responsibility principle)を、"各モジュールはひとつのことを適切に実行するべき"、と言い換えている。新たな定義はOOPに加えて、関数型プログラミングやマイクロサービス設計にも適用が可能なものになっている。

開放-閉鎖の原則(open-closed principle)は、"モジュールは書き直すのではなく、再利用や追加が可能であるべき"、となる。これはFPならば"フックポイント"を使って実現可能であり、OOPではごく自然な特性である。

さらにLiskovの置換原則(Liskov substitution principle)については、"同じ動作をすると宣言されている場合には、あるものから別のものへの置き換えが可能であるべき"、と定義している。 この定義は、ダックタイピングやフィルタ機能を使うことで、動的プログラミング言語に適用することが可能になる。

氏の再定義によれば、インターフェース分離の原則(interface segregation principle)は、"必要でないものはクライアントから隠蔽するべき"、となる。言い換えれば、クライアントはドキュメントのみを知っていればよい、ということだ。この定義は、分離デプロイメントやドキュメントセットの分離を通じて、マイクロサービスにも適用することができる。

依存性逆転の原則(dependency inversion principle)の定義については、"具象ではなく、抽象に依存すべき"、と同じままだ。抽象化が本質的概念であることには変わりなく、OOP、FP、さらには(直接的な通信ではなくメッセージパッシングを使うことで)マイクロサービスにも適用可能である、というのが氏の考えである。

しかし他の筆者らは、マイクロサービスに関して異なる見方をしている。Paulo Merson氏は、SOLID原則はOOPには適しているが、マイクロサービスには完全には当てはまらないと主張して、マイクロサービスのための新たな原則セット: IDEALSを提案している。IDEALSとは、インターフェース分離、デプロイ可能(deployability)、イベント駆動(event driven)、一貫性よりも可用性(availability over consistency)、疎結合(loose-coupling)、そして単一責任である。

この記事に星をつける

おすすめ度
スタイル

BT