何をオブジェクト化しないか
設計において何をオブジェクト化するか、について考えることがあったのでメモ。
何をオブジェクト化するか
通常、設計においてはソフトウェアの仕様から「何をオブジェクト化するか」を考えます。「オブジェクト化する」とは、ソフトウェアの主要な関心事に名前をつけ、責務を分配し、他のオブジェクトとの協調関係を定義する行為です。
もしここで、アプリケーションにおいては重要であるにも関わらず無視される関心事が出てくると、その関心事は名前をつけられたり明確な責務を定義されることもなく、ほかのコードに埋もれます。これにより、
- 変更容易性の低下
- 可読性の低下
- テスト容易性の低下
を引き起こします。つまり、保守性という面での品質が低下するわけです。
重要な関心事は変更頻度が高いことが多いので、保守性の低下は禍根を残します。
なので、重要な関心事はきっちりとオブジェクト化することが大事です。
何をオブジェクト化しないか
しかし、過度なオブジェクト化は逆に可読性を下げます。
例えば、名前を表すnameフィールドを持ったUserクラスを考えてみます。このnameをNameクラスのオブジェクトとして持つと、Nameクラスの中身を気にする必要が出てきてしまうことで可読性が多少下がります。標準の文字列型で持ったほうがより直接的でわかりやすいでしょう。
一方でオブジェクト化をしない場合、その概念に関する柔軟性を犠牲にしていることになります。
例えばUserクラスにログインに関するロジックをもたせている場合、ログインロジックの変更にはUserクラスの変更が必要になります。ログインオブジェクトとして切り出せばログインロジックの修正でUserに手を加えることはなくなりますし、そこにStrategyパターンを適用すればユーザーごとにログインロジックを変えるといったことも可能になります。
つまり、可読性と柔軟性の間でトレードオフが生じているわけです。
このバランスは、柔軟性をどこにどれだけ提供したいか、どの概念をコードの中で際立たせたいかによります。
このように、すべてをオブジェクトとして意識しつつ、可読性と柔軟性のバランスを考慮して最適な粒度のオブジェクトにまとめることを考えることが大事だと思いました。
