美しき対称なソフトウェア設計

アダコテックの柿崎です。今日はソフトウェア設計の話をしたいと思います。

よいソフトウェアとは何か？と問われると、エンジニアの方々はどう答えるでしょうか？性能が高い、機能追加が容易、バグが少ない、など様々な観点があり一意に定まるものではない問いです。また、仕様書やソースコードを見て「なんとなくこれはよくない」とか「これはぱっと見よさそう」とかエンジニアであれば感じると思います。ただ、これはエンジニアの感覚に頼っていてなかなか言語化できないですよね。今回は、そんなエンジニアの感じる「よさそう」という感覚を「対称性」に着目してひもといていこうと思います。

対称なものって美しいですよね。

人類は対称なものを美しいと感じる感覚が備わっているようです。ソフトウェアは芸術とは違いますが、対称性を意識した設計はレビュアーに「なんとなくよい」という美的感覚を与え、また実際に扱う上でも保守性の高いものが実現できます。

では、対称性はソフトウェア設計のどこに現れるでしょうか？今回は

・クラス図
・ER図
・API(ソースコード)

で見ていこうと思います。

クラス図における対称性

次の２つのクラス図を比較してください

美しく設計されたクラスは継承と委譲がバランスよく、図面の縦と横のバランスがよくなり、１つのクラスに機能が集中するということも避けられています。

Badな例としてはクラスをgitのブランチのように扱ってしまうパターンを挙げました。機能拡張を継承に頼ってしまい、また派生バージョンがあらわれると途中のバージョンから親子関係が分岐してしまうので、図面上からもバランスが悪く、仕様変更した場合の影響範囲が大きく収拾がつかなくなります。

クラス図から現れる対称性は

・各クラスのボリュームは適切か
・クラス間で適切に委譲がされているか
・共通のインタフェースがまとめられているか

といった観点でレビューできるかと思います。

ER図における対称性

次の２つのER図をご覧下さい

美しいER図は、個々のEntityのサイズ感がそろっている点、Relationを表す線がシンプルで絡まっていないので、必要なデータをとってくるためのクエリも見通しが立ちやすいです。

一方、BadなER図はやたら大きなテーブルができていたり、Relationがこんがらがっていたりするため、必要なデータをどういうクエリで取ってくるのかわからなくなってきます。

ER図から現れる対称性は

・飛び抜けて大きなテーブルができていないか
・ヒエラルキーをまたいだリレーションが貼られていないか(線がこんがらがらない)

といった観点でレビューできるかと思います。

APIにおける対称性

APIにおける対称性とはopen⇔close、create⇔delete、push⇔popといった対になる概念を意識して作られていることを指します。このような設計を意識することで、アプリケーションのソースコードも

A.open()
...
初期化
...
B.create()
...
なんらかの処理
...
B.delete()
...
終了処理
...
A.close()

このようにエディタ上で上下に対称な実装になるはずです。

もし、openメソッドがあるのにcloseがないとか、createがないのにdeleteだけあるというAPI設計が出されたら、

「このファイルハンドルはどこでcloseされるんだろうか」
「もしかしてどこかでメモリ破壊が起こるんじゃないだろうか」

とか心配になりますよね。このように対称なAPI設計は扱う上でも明瞭になり、保守性の高い設計と言えると思います。

以上、今回は「対称性」に着目した美しい設計を紹介しました。人の直感となじみがよいので設計や実装のレビューで取り入れてみてはいかがでしょうか。