この記事は設計こばなし Advent Calendar 2023の1日目です。

概要

過去（15年前の2008年。開発経験6年目の28歳のとき）におこなった実際の開発案件を思い出し、ダメな設計をSOLID原則の単一責任の原則の観点から振り返る。

開発対象

開発対象はつぎの要件のWindows Formアプリケーション

要件

Windows Formアプリケーション
言語: C#
無線でターゲット装置の温度、無線強度を受信する
無線接続状態（接続・未接続）を表示する
温度、無線強度をサードパーティ製のグラフ描画ライブラリを使い折れ線グラフを描画する
無線通信設定（周波数帯の選択、無線伝送速度設定）
無線セキュリティ設定（暗号化の有無、暗号キー）
グラフ表示更新間隔設定（100ms〜1000ms）

ブロック図

ダメな設計

クラス図はつぎのとおり。

クラス図

改善点

クラス図から設計の改善点を考えた。

マネージャーという名の神クラス

まずマネージャーというクラス名が抽象的すぎる。
マネージャーという名のもと、管理するものがあれもこれもと集約してしまう。
神クラスになっていく兆候と思った。
クラスの責務が明確になる命名を心がけようと思った。

設定クラスが単一責務になっていない

設定クラスに設定項目のすべてが集約している。
単一責務の原則はクラスを変更する理由はひとつであること、と言っている。
このクラスは設定項目が分類されず集約されている。例えばグラフ表示更新間隔に関するロジックが変更になったときに設定クラス全体に変更影響が及ぶ可能性がある。
設定項目の関心が分離されていない、密結合な構造とも言えそうだ。
無線関連の設定項目（周波数帯の選択、無線伝送速度設定）、画面表示の設定項目（グラフ表示更新間隔）などと意味のあるグループに分類・分割し、それぞれを疎結合な構造にすることをこころがけようと思った。

感想

振り返ると当時はどう要件を実現するか実現手段に手一杯で高凝集、疎結合な設計にする、という観点まで考えることができなかった。