この記事は私が「Clean Architecture 達人に学ぶソフトウェアの構造と設計」を読んだ際の備忘録です。
本記事を読んで興味を持たれたら是非読んでみてください。
本記事では、参考書籍にて語られている「開放/閉鎖の原則」に関わる部分についてまとめています。
「開放/閉鎖の原則」は「モジュールは拡張に対して開いていて、修正に対して閉じているべき」という原則です。
プログラムの変更理由は、以下の4種類に大別できると言われています。
「開放/閉鎖の原則」は、「機能追加をする時、既存モジュールを変更せず、新規モジュールを追加して実装できるべき」と換言できると思います。
この原則に従っている箇所への機能追加は、新規モジュール追加とメインモジュールの改修のみで実装できるはずです。
なぜ「開放/閉鎖の原則」を守った方が良いか考えるために、違反するとどうなるか考えます。
「開放/閉鎖の原則」に違反している場合、機能拡張時にも既存モジュールへの変更が必要になります。
既存モジュールに変更を加える時は、モジュールへ依存している他のモジュールへの影響も考慮する必要があります。
変更時に考慮すべき範囲が広くなり、開発工数が大きくなりやすく、バグも発生しやすくなります。
「開放/閉鎖の原則」を守っている箇所への機能追加では、新規モジュール追加とメインモジュールの改修のみが発生します。
このため既存モジュールへの影響が小さくなり、変更時に考慮すべき範囲を狭くできます。
しばしば「開放/閉鎖の原則」と同時に語られる「YAGNI」という原則があります。
「YAGNI」は「You aren’t gonna need it」の略で、意訳すると「きっとそれは必要にならない」のような意味になります。
この原則は、必要そうな物は実際に必要になってから作れば良いという考えを示しています。
「開放/閉鎖の原則」は拡張される機能に対しては効果的ですが、拡張されない機能に対しては設計過剰になってしまいます。
拡張が確定している機能は「開放/閉鎖の原則」に従い、それ以外は必要になったら「開放/閉鎖の原則」に従うように改修した方が良いです。
ここまで読んでいただきありがとうございます。
次回は、「SOLID原則」の一つである「リスコフの置換原則」について書く予定です。
入会申込
ログイン
